Andreas Gustafsson <g...@gson.org> writes: > Riccardo Mottola wrote: >> while doing a full update with today's pkgsrc con current, I get: > [..] >> /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined >> reference to `epoxy_has_glx' > > I believe this is a pkgsrc-current issue and not a NetBSD-current nor > emacs-current issue, because I'm also getting the "undefined reference > to `epoxy_has_glx'" when I try to build emacs25 after I updated pkgsrc > (but not the OS) on a NetBSD 8.0/amd64 system.
Thanks - so this is almost certainly not a stray .h issue on Riccardo's system. > Also, I tried to reproduce the problem by building emacs25 on a > freshly installed NetBSD-current system with no pre-existing > packages, but there it built successfully. And did it build libepoxy in this case? [very fuzzy] This suggests that libepoxy is sometimes used if present in an inconsistent way, perhaps due to shadowing of includes. > On the 8.0 system where the emacs25 build fails, libgdk-3.so has > a reference to epoxy_has_glx: > > $ nm /usr/pkg/lib/libgdk-3.so|grep epoxy_has_glx > U epoxy_has_glx > U epoxy_has_glx_extension > $ > > Adding -Wl,--verbose to the emacs25 link line, I see that it's > trying to link libepoxy from /usr/X11R7/lib: > > libepoxy.so.0 needed by > /usr/pkgsrc/editors/emacs25/work/.buildlink/lib/libgtk-3.so > found libepoxy.so.0 at /usr/X11R7/lib/libepoxy.so.0 > > which does not define expoxy_has_glx. On my -7 system, there is no libepoxy in /usr/X11R7. That probably explains why I don't see this. On my -8 system, there is libepoxy in /usr/X11R7 which defines epoxy_has_glx_extension but not epoxy_has_glx. > On the -current system where the emacs25 build succeeds, libgdk-3.so > does not have a reference to epoxy_has_glx: > > $ nm /usr/pkg/lib/libgdk-3.so|grep epoxy_has_glx > U epoxy_has_glx_extension > $ > I have no X11_TYPE definition in mk.conf, being of the firm conviction > that the default settings need to work. Agreed. Really both need to work. It seems that there are perhaps different headers and in the bad case the header with epoxy_has_glx is picked up but the lib without it is used. -8 has 1.3.1, and pkgsrc 1.4.3 So to resolve: - I realize libepoxy is in different paths, but the shlib major is 0 in both cases, yet they define differenet symbols. That seemed wrong at first, but pkgsrc has the extra and is newer, so it's not actually wrong. - We don't have a good way to force using the pkg vs native version of many libs separately due to how - I don't see a builtin.mk for epoxy. Adding one may finesse the issue by having the base version be good enough and thus have the pkg version not installed. - we could add the symbol to base, or upgrade base epoxy. That's just barely allowed, since the shlib major isn't changing. - we could patch gtk3 to not use it, even if present, if it doesn't add anything important.