Sean Champ <sean.p.champ%gmail.com@localhost> writes:
> I'm testing out the builds for my pkgsrc configuration on FreeBSD by
> building wip/emacs-git for an Xaw toolkit with X11_TYPE=native and
> XAW_TYPE=neXtaw. I've defined my X11_BASE=/usr/local/include for the pkgsrc
> builds on FreeBSD.
/usr/local/include is very strange for this. That would mean include
files are at /usr/local/include/include, libs at /usr/local/include/lib
and programs at /usr/local/include/bin!
You could of course build xorg from pkgsrc by using modular. It is
valid to want to use base and I don't mean to discourage you, but am
just pointing that out.
I do not follow "defined X11_BASE". With native, for each operating
system, there is a location where the base system installs X11. And
pkgsrc spells it X11BASE, with no _. This is set in mk/bsd.pkg.mk, per
platform (and perhaps should be in platform.mk, but it's not, mostly).
> In the process of this, I've discovered that a number of the buildlink3.mk
> files under x11 are using a pathname such as ${X11BASE}/lib/pkgconfig/sm.pc
> for locating a package's pc file. I understand that this pathname might be
> where sm.pc would be available on most hosts.
See x11-links. That is supposed to create a buildlink tree to
wherever X is.
> With pkgsrc on FreeBSD under this configuration, sm.pc would be available
> at ${X11BASE}/libdata/pkgconfig/sm.pc.
The first question is: when you install FreeBSD including X11, before
you do anything about pkgsrc at all, what is the X11 preffix and where
is sm.pc? Using "native" means that pkgsrc does not build X11, but uses
the version already installed by the oeprating system.
The normal thing is to put X11 in /usr/X11R7. On NetBSD 9, that file is
at /usr/X11R7/lib/pkgconfig/sm.pc However, it seems that FreeBSD has
put it in libdata.
> With sm.pc not found - though it's available on the host - this may affect
> the pkgtools/x11-links build and any builds that would use the x11-links
> pkg together with X11_TYPE=native. With a small patch, though. sm.pc is
> found ... and then I can debug the next instance, lol
>
> To try to make this pathname more portable, I've begun testing out a patch
> where I've defined a variable PKGCONFIG_DIR?=lib/pkgconfig in mk/buildlink3/
> pkgconfig-builtin.mk I'm then patching each buildlink3.mk such as to use
> the following, for example in x11/libSM/buildlink3.mk
> ~~~~~
> .if ${X11_TYPE} != "modular" && \
> !exists(${X11BASE}/${PKGCONFIG_DIR}/sm.pc) && \
> !exists(${X11BASE}/lib${LIBABISUFFIX}/pkgconfig/sm.pc)
> .include "../../mk/x11.buildlink3.mk"
> .else
> [...]
> ~~~~~
The basic issue is that FreeBSD's pkgconfig files are in an unusual
place and the fix is probably to cause the bl3 machinery to symlink them
into the normal place. Changing all bl3 files does not seem like a
good approach.
> I can then set PKGCONFIG_DIR=libdata/pkgconfig in my mk.conf, such that the
> pkgsrc build can find the existing sm.pc file on the host.
Your mk.conf is where your preferences go. If that is where it is in
FreeBSD for everyone, then we should -- somehow -- adjust
platform/FreeBSD.mk to define something so this works for everything
> After patching each x11 pkg-port for this, then rebuilding and reinstalling
> pkgtools/x11-links it seems to be working out. Perhaps a similar patch
But why are building each x11 package if you are using native?
> could be applied for each buildlink3.mk in each pkg that would provide a
> library referenced under the pkgtools/x11-links files dir. I'm certain that
> there may be other ports using a simlar pkgconfig dir, outside of those
> using X11_TYPE in the build. I suppose I'm just focusing on the X11_TYPE
> ports for now.
>
> Before developing a complete patch for this approach, I though it might be
> helpful to communicate with the list here. I'm not certain what the
> consensus could be about defining a PKGCONFIG_DIR as such, or defining it
> in mk/buildlink3/pkgconfig-builtin.mk.
I think we (you!) need to figure out how to hoist thie difference in
pkg-config file location to one place, rather than changing lots of
files.
A big clue is that the build environment sees the buildlink tree, not
the host libs.
> To facilitate the USE_BUILTIN definitions, I'm also using the following in
> mk.conf
> ~~~~~
> USE_HOST_LIBS+= bzip2 zlib png freetype2 libXmu libXext libXt libX11
> libXaw3d
> USE_HOST_LIBS+= libXau libXdmcp libXext libX11 libXpm libXt xorgproto
> USE_HOST_LIBS+= libXft libSM libICE
>
> .for P in ${USE_HOST_LIBS}
> USE_BUILTIN.${P}= yes
> PREFER.${P}= native
> PREFER_NATIVE+= ${P}
> CHECK_BUILTIN.${P}= no
> .endfor
> ~~~~~
>
> It seems to be working out, so far.
Generally pkgsrc is configured by default to use native versions when
they are acceptable, so I would think that you shouldn't need to do
this.
> I've avoided setting LIBABISUFFIX=data here. It seems that might have a
> similar affect in e.g x11/libSM/buildlink3.mk and it would not need a
> patch on the pkgsrc tree, but I'm not sure if it's the right approach -
> assuming LIBABISUFFIX must have some other purpose.
LIBABISUFFIX, as I understand it, is a workaround for the linuxy
practice of putting native libraries in /usr/lib64 (eg. for x86_64) and
emulation libaries (e.g. i386 for a machine that is actually x86_64) in
/usr/lib. NetBSD practice is "don't do that" and I think that's how
FreeBSD is too. Then you shouldn't need that. If you are using that
for some other purpose, that's probably not the right thing to do.
Attachment:
signature.asc
Description: PGP signature