Re: Failure to build "current" emacs from pkgsrc on current
Riccardo Mottola writes: > … I updated once again pkgsrc, rebuilt > gtk... and now building of emacs completed! > > So that issue is solved for me. One issue I have is at the creation of new frames. The visible frame truncates rapidly to show a short 4 lines from the buffer. What I have in `.emacs' is a preference for 35 lines. (add-to-list 'default-frame-alist '(height . 35)) (add-to-list 'default-frame-alist '(width . 80)) Calling `emacs -Q' also sees the buffer truncate to 4 lines visible when repeatedly creating new frames. The call used is from macos/xquartz to netbsd ssh -Xf wakeman /usr/pkg/bin/emacs-26.2 ssh -Xf wakeman /usr/pkg/bin/emacs-26.2 -Q This is with the following build detail GNU Emacs 26.2 (build 1, x86_64--netbsd, GTK+ Version 3.24.1) of 2019-05-01 NetBSD wakeman 8.99.37 NetBSD 8.99.37 (GENERIC) #0: Wed Apr 24 20:53:10 UTC 2019 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 -- © 2019 Van L gpg using EEF2 37E9 3840 0D5D 9183 251E 9830 384E 9683 B835 "I posted it on the Internet the Internet says it was fake." - Soulja Boy
Re: Failure to build "current" emacs from pkgsrc on current
Hi Leonardo, Leonardo Taccari wrote: (More information was appended to PR pkg/53688 opened by Andreas but I will try to summarize all possible details here too for completeness, TLDR; emacs25-25.3nb10 and emacs26-26.1nb3 should now works properly.) Despite the buildlink3.mk change was needed it didn't solve the problem originally reported by Riccardo. Maya suggested to pass `-Wl,--verbose' to get more details about the linking failures (by adding them to src/Makefile in `temacs$(EXEEXT):' target) and indeed this pointed out the following: sorry for the confusion. I updated once again pkgsrc, rebuilt gtk... and now building of emacs completed! So that issue is solved for me. Thanks. Riccardo
Re: Failure to build "current" emacs from pkgsrc on current
Hello Greg, Andreas and Riccardo,
Leonardo Taccari writes:
> [...]
> I have just added it to buildlink3.mk, please let me know if that
> fixes the problem you have reported! (just a `make replace' in
> emacs or any other problematic package should be enough to test
> that)
> [...]
(More information was appended to PR pkg/53688 opened by Andreas
but I will try to summarize all possible details here too for
completeness, TLDR; emacs25-25.3nb10 and emacs26-26.1nb3 should
now works properly.)
Despite the buildlink3.mk change was needed it didn't solve the
problem originally reported by Riccardo.
Maya suggested to pass `-Wl,--verbose' to get more details about
the linking failures (by adding them to src/Makefile in `temacs$(EXEEXT):'
target) and indeed this pointed out the following:
libepoxy.so.0 needed by
.../pkgsrc/editors/emacs25/work/.buildlink/lib/libgtk-3.so
found libepoxy.so.0 at /usr/X11R7/lib/libepoxy.so.0
Inspecting the corresponding lines in work.log I have noticed that there
were extra and early `-Wl,-rpath,/usr/X11R7/lib' flags.
The emacs configure script was injecting them on NetBSD and OpenBSD.
The patch applied just comment out that part that is handled by
pkgsrc in configure{,.ac}.
Sorry again for breaking them and please let me know if you find
any regression.
Re: Failure to build "current" emacs from pkgsrc on current
Hello Andreas, Greg and Riccardo, Andreas Gustafsson writes: > Greg, Riccardo, > > Please disregard the parts of my earlier mail that pertained to > tests run under NetBSD-current. I had missed the fact that > ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz is only > regenerated weekly, and accidentally tested using a pkgsrc.tar.gz > that was five days old and still had gtk+-3.22.30.nb3 rather than > gtk+-3.24.1. > > I will rerun my test and report the new results in a pkgsrc PR, > since current-users is not really the right forum for this. > [...] I am probably responsable for breaking it when updating it to 3.24.1, sorry! gtk+-3.24.1 needs libepoxy>=1.4 and that requirements was specified via BUILDLINK_API_DEPENDS.libepoxy in pkgsrc/x11/gtk3/Makefile. However, I have accidentally forgotten to add t in pkgsrc/x11/gtk3/buildlink3.mk too. I have just added it to buildlink3.mk, please let me know if that fixes the problem you have reported! (just a `make replace' in emacs or any other problematic package should be enough to test that) Sorry again and thank you for your patience and analysis of the problem!
Re: Failure to build "current" emacs from pkgsrc on current
Greg, Riccardo, Please disregard the parts of my earlier mail that pertained to tests run under NetBSD-current. I had missed the fact that ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz is only regenerated weekly, and accidentally tested using a pkgsrc.tar.gz that was five days old and still had gtk+-3.22.30.nb3 rather than gtk+-3.24.1. I will rerun my test and report the new results in a pkgsrc PR, since current-users is not really the right forum for this. -- Andreas Gustafsson, g...@gson.org
Re: Failure to build "current" emacs from pkgsrc on current
Andreas Gustafsson 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.
Re: Failure to build "current" emacs from pkgsrc on current
Riccardo Mottola writes: > Hi Greg, > > Greg Troxel wrote: >> >> Yes, but it can hit an error and exit without finishing. >> >> So I would run it again and see if it reports that there's nothing to >> do. > > I did re-run it and it breaks out in the same place! That in general isn't a good way to use pkg_rr. Without -k, it will stop on error. Then, my approach is to either 1) fix the package so it doesn't error, 2) use -X to exclude rebuilding it, or 3) add -k. The only real reasons not to use -k are: - fear of things going badly if many things fail (not really an issue) - wanting to fix things along the way, e.g. getting ready for a branch - not wanting to rebuild things multiple times after something succeeds later (if you use ccache, it's not that big a deal) So until pkg_rr has finished all the way and you are aware of what if anything didn't work, things may be in an inconsistent state. >> On netbsd-7 amd64, 2018Q3: >> >>> nm -u /usr/pkg/lib/libgdk-3.so|egrep glx >> U epoxy_glx_version >> U epoxy_has_glx_extension > > $ nm -u /usr/pkg/lib/libgdk-3.so|egrep glx > U epoxy_glx_version > U epoxy_has_glx > U epoxy_has_glx_extension That explains the error, and now to explain the symbol's presence... >> that looks like you got an >> in-progress addition and the usual python >> default vs 36/37 pkg_chk issue. not really concerning. > > Ok, I'll hope it will go away when pkg_rolling-replace finishes. Well, they won't. With python, there is a default version, usually 27, and more and more things are using 36 or 37. What's needed is a way to report that foo/py-bar needs rebuilding for PYPREFIX 27 and 36, and so far between how pkg_chk behaves and how pkg_rr behaves that doesn't work well. python packages for the default python version get replaced ok. And this almost certainly is not related to your epoxy problem. >> 2) to make sure you have no old headers that don't belong, in >> /usr/include, /usr/X11R*/include, or /usr/pkg/include. Use find with >> ctime to find .h files not written during update, and pkg_admin check to >> look at file checksums vs installed, and then find /usr/pkg -atime +7 to >> find files not read by pkg_admin check and investigate. > > something that did not upgrade during system update? hmm here I don't > follow you exactly what to find though. System updating adds the new version of files, for files that are in the new version. There is an obsolete mechanism that "postinstall fix" invokes that will remove some old files. However, I have found over the years (I have been running NetBSD since 0.8) that sometimes depending on the upgrade sequence there are header files that are not part of the current install and are left over somehow, and I have found this to cause problems. So when things go badly, I tend to look at all the .h files and be sure that they are only the set that should be installed, and clean up cruft. After an install, the ctime of each is modified, so find with -ctime can find files that haven't been modified in years. Old libraries should be ok, but old .h files are possibly trouble (we support old ABI, but not API).
Re: Failure to build "current" emacs from pkgsrc on current
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. 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. 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 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. -- Andreas Gustafsson, g...@gson.org
Re: Failure to build "current" emacs from pkgsrc on current
Hi Greg, Greg Troxel wrote: Yes, but it can hit an error and exit without finishing. So I would run it again and see if it reports that there's nothing to do. I did re-run it and it breaks out in the same place! I don't have much useful advice, other than to start using nm or objdump on the libraries in question and trace which symbols are defined where. On netbsd-7 amd64, 2018Q3: nm -u /usr/pkg/lib/libgdk-3.so|egrep glx U epoxy_glx_version U epoxy_has_glx_extension $ nm -u /usr/pkg/lib/libgdk-3.so|egrep glx U epoxy_glx_version U epoxy_has_glx U epoxy_has_glx_extension But I'm not really sure epoxy is. disc$ pkg_info | grep epoxy libepoxy-1.4.3 Library for OpenGL function pointer management that looks like you got an in-progress addition and the usual python default vs 36/37 pkg_chk issue. not really concerning. Ok, I'll hope it will go away when pkg_rolling-replace finishes. My only other suggestions are 1) to make sure that you have rebuilt *everything* after any change from X11_TYPE from native to/from modular (via "pkg_admin set rebuild-yes \*"). 2) to make sure you have no old headers that don't belong, in /usr/include, /usr/X11R*/include, or /usr/pkg/include. Use find with ctime to find .h files not written during update, and pkg_admin check to look at file checksums vs installed, and then find /usr/pkg -atime +7 to find files not read by pkg_admin check and investigate. something that did not upgrade during system update? hmm here I don't follow you exactly what to find though. I ill attempt cleaning and reinstalling epoxy and gdk. Riccardo
Re: Failure to build "current" emacs from pkgsrc on current
Riccardo Mottola writes:
> Greg Troxel wrote:
>> Riccardo Mottola writes:
>>
>>> while doing a full update with today's pkgsrc con current, I get:
>> by 'full update', what do you mean?
>
> I updated kernel, tools & distribtion to latest.
>
> Then I did update pkgsrc and run pkg_rolling-replace -uv
>> host os?
>
> amd64, NetBSD-current
>
> NetBSD disc 8.99.25 NetBSD 8.99.25 (HP620) #9: Mon Oct 22 10:51:47
> CEST 2018 multix@disc:/usr/obj/sys/arch/amd64/compile/HP620 amd64
So that should be ok.
>>> /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined
>>> reference to `epoxy_has_glx'
>> I dimly remember seeing epoxy/glx issues where various systems have
>> different setings.
>>
>> Are you really sure gdk and everything it depended on had been rebuilt?
>>
>> Does anything else that depends on gdk fail?
>
> that is a good question, shouldn't pkg_rolling-replace -uv handle that
> for me?
Yes, but it can hit an error and exit without finishing.
So I would run it again and see if it reports that there's nothing to
do.
I don't have much useful advice, other than to start using nm or objdump
on the libraries in question and trace which symbols are defined where.
On netbsd-7 amd64, 2018Q3:
> nm -u /usr/pkg/lib/libgdk-3.so|egrep glx
U epoxy_glx_version
U epoxy_has_glx_extension
But I'm not really sure epoxy is.
> I just did run lintpkgsrc -i
>
> disc$ lintpkgsrc -i
> Scan Makefiles: ._
> Bogus: ${GITHUB_PROJECT:tl}-6.3 (from /usr/pkgsrc/geography/gpxsee/Makefile)
> ...
> /usr/pkgsrc/net/py-onionbalance/Makefile: Cannot locate
> net/py-onionbalance/Makefile.common in
> . /usr/pkgsrc/net/py-onionbalance
>
> /usr/pkgsrc/net/py-onionbalance/Makefile: make:
> "/usr/pkgsrc/net/py-onionbalance/Makefile" line 3: Could not find
> net/py-onionbalance/Makefile.common make: Fatal errors encountered --
> cannot continue
> Cannot extract py-onionbalance- version
> (/usr/pkgsrc/net/py-onionbalance/Makefile)
> 15993 packages
> Unknown package: 'ap24-subversion' version 1.10.3
> Version mismatch: 'py-expat' 3.6.7 vs 2.7.15
> Version mismatch: 'py-expat' 3.7.1 vs 2.7.15
that looks like you got an in-progress addition and the usual python
default vs 36/37 pkg_chk issue. not really concerning.
My only other suggestions are
1) to make sure that you have rebuilt *everything* after any change from
X11_TYPE from native to/from modular (via "pkg_admin set rebuild-yes
\*").
2) to make sure you have no old headers that don't belong, in
/usr/include, /usr/X11R*/include, or /usr/pkg/include. Use find with
ctime to find .h files not written during update, and pkg_admin check to
look at file checksums vs installed, and then find /usr/pkg -atime +7 to
find files not read by pkg_admin check and investigate.
Re: Failure to build "current" emacs from pkgsrc on current
Hi,
Greg Troxel wrote:
Riccardo Mottola writes:
while doing a full update with today's pkgsrc con current, I get:
by 'full update', what do you mean?
I updated kernel, tools & distribtion to latest.
Then I did update pkgsrc and run pkg_rolling-replace -uv
host os?
amd64, NetBSD-current
NetBSD disc 8.99.25 NetBSD 8.99.25 (HP620) #9: Mon Oct 22 10:51:47 CEST
2018 multix@disc:/usr/obj/sys/arch/amd64/compile/HP620 amd64
/usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined
reference to `epoxy_has_glx'
I dimly remember seeing epoxy/glx issues where various systems have
different setings.
Are you really sure gdk and everything it depended on had been rebuilt?
Does anything else that depends on gdk fail?
that is a good question, shouldn't pkg_rolling-replace -uv handle that
for me?
I just did run lintpkgsrc -i
disc$ lintpkgsrc -i
Scan Makefiles: ._
Bogus: ${GITHUB_PROJECT:tl}-6.3 (from /usr/pkgsrc/geography/gpxsee/Makefile)
...
/usr/pkgsrc/net/py-onionbalance/Makefile: Cannot locate
net/py-onionbalance/Makefile.common in . /usr/pkgsrc/net/py-onionbalance
/usr/pkgsrc/net/py-onionbalance/Makefile: make:
"/usr/pkgsrc/net/py-onionbalance/Makefile" line 3: Could not find
net/py-onionbalance/Makefile.common make: Fatal errors encountered --
cannot continue
Cannot extract py-onionbalance- version
(/usr/pkgsrc/net/py-onionbalance/Makefile)
15993 packages
Unknown package: 'ap24-subversion' version 1.10.3
Version mismatch: 'py-expat' 3.6.7 vs 2.7.15
Version mismatch: 'py-expat' 3.7.1 vs 2.7.15
Strange...
Riccardo
Re: Failure to build "current" emacs from pkgsrc on current
Riccardo Mottola writes: > while doing a full update with today's pkgsrc con current, I get: by 'full update', what do you mean? host os? > /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined > reference to `epoxy_has_glx' I dimly remember seeing epoxy/glx issues where various systems have different setings. Are you really sure gdk and everything it depended on had been rebuilt? Does anything else that depends on gdk fail?
Failure to build "current" emacs from pkgsrc on current
Hi, while doing a full update with today's pkgsrc con current, I get: CC fontset.o CC fringe.o CC image.o CC xgselect.o CC terminfo.o CC lastfile.o CC gmalloc.o CCLD temacs /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined reference to `epoxy_has_glx' gmake[2]: *** [Makefile:600: temacs] Error 1 gmake[2]: Leaving directory '/usr/pkgsrc/editors/emacs26/work/emacs-26.1/src' gmake[1]: *** [Makefile:418: src] Error 2 gmake[1]: Leaving directory '/usr/pkgsrc/editors/emacs26/work/emacs-26.1' gmake: *** [Makefile:1101: bootstrap] Error 2 *** Error code 2 Stop. make[1]: stopped in /usr/pkgsrc/editors/emacs26 *** Error code 1 Any ideas? Riccardo
