Re: In tree builds broken in lib/ncurses?
On Jun 16, 2014, at 2:14 PM, Steve Kargl wrote: > On Mon, Jun 16, 2014 at 11:01:59AM -0600, Warner Losh wrote: >> >> On Jun 16, 2014, at 12:18 AM, Steve Kargl >> wrote: >> >>> On Sun, Jun 15, 2014 at 08:02:38AM -0600, Ian Lepore wrote: It looks like this is a SUBDIR_PARALLEL build fallout. I've finally committed the fine-grained dependency fix I've been sitting on for weeks, could you please try updating to r267511 and then applying the attached to see if it fixes it? >>> >>> AFAICT, your patch does not fix the problem. After a >>> 'svn update' and buildworld/installworld cycle, I still >>> the problem >>> >>> % cd /usr/src >>> % make clean && make cleandepend >>> % make clean && make clean depend >> >> % make obj > > Thanks for the pointer. I believe that in the 20 decades that > I've used FreeBSD (386bsd+patchkit), I've never had the need to > do an explict 'make obj'. In-tree builds simply worked. It isn’t a path that gets exercised too much these days. Not surprised it broke. >>> % cd lib/ncurses >>> % make depend >>> % make >>> >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/src/lib/ncurses/ncursesw >>> *** Error code 1 >> >> If I do the above, it works. So when we last imported ncurses,i >> it looks like it broke the non-obj-tree based build. > > Sure would be nice if this could be fixed. Ideally, the ncurses importer would clean this up… Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: In tree builds broken in lib/ncurses?
On Mon, Jun 16, 2014 at 11:01:59AM -0600, Warner Losh wrote: > > On Jun 16, 2014, at 12:18 AM, Steve Kargl > wrote: > > > On Sun, Jun 15, 2014 at 08:02:38AM -0600, Ian Lepore wrote: > >> > >> It looks like this is a SUBDIR_PARALLEL build fallout. I've finally > >> committed the fine-grained dependency fix I've been sitting on for > >> weeks, could you please try updating to r267511 and then applying the > >> attached to see if it fixes it? > >> > > > > AFAICT, your patch does not fix the problem. After a > > 'svn update' and buildworld/installworld cycle, I still > > the problem > > > > % cd /usr/src > > % make clean && make cleandepend > > % make clean && make clean depend > > % make obj Thanks for the pointer. I believe that in the 20 decades that I've used FreeBSD (386bsd+patchkit), I've never had the need to do an explict 'make obj'. In-tree builds simply worked. > > % cd lib/ncurses > > % make depend > > % make > > > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/src/lib/ncurses/ncursesw > > *** Error code 1 > > If I do the above, it works. So when we last imported ncurses,i > it looks like it broke the non-obj-tree based build. Sure would be nice if this could be fixed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Jun 16, 2014, at 12:18 AM, Steve Kargl wrote: > On Sun, Jun 15, 2014 at 08:02:38AM -0600, Ian Lepore wrote: >> >> It looks like this is a SUBDIR_PARALLEL build fallout. I've finally >> committed the fine-grained dependency fix I've been sitting on for >> weeks, could you please try updating to r267511 and then applying the >> attached to see if it fixes it? >> > > AFAICT, your patch does not fix the problem. After a > 'svn update' and buildworld/installworld cycle, I still > the problem > > % cd /usr/src > % make clean && make cleandepend > % make clean && make clean depend % make obj > % cd lib/ncurses > % make depend > % make > > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src/lib/ncurses/ncursesw > *** Error code 1 If I do the above, it works. So when we last imported ncurses, it looks like it broke the non-obj-tree based build. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: In tree builds broken in lib/ncurses?
On Sun, Jun 15, 2014 at 08:02:38AM -0600, Ian Lepore wrote: > > It looks like this is a SUBDIR_PARALLEL build fallout. I've finally > committed the fine-grained dependency fix I've been sitting on for > weeks, could you please try updating to r267511 and then applying the > attached to see if it fixes it? > AFAICT, your patch does not fix the problem. After a 'svn update' and buildworld/installworld cycle, I still the problem % cd /usr/src % make clean && make cleandepend % make clean && make cleandepend % cd lib/ncurses % make depend % make *** Error code 1 Stop. make[1]: stopped in /usr/src/lib/ncurses/ncursesw *** Error code 1 Stop. make: stopped in /usr/src/lib/ncurses -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Sat, 2014-06-14 at 23:12 -0700, Steve Kargl wrote: > On Sat, Jun 14, 2014 at 07:44:29PM -0600, Warner Losh wrote: > > On Jun 14, 2014, at 7:30 PM, Steve Kargl > > wrote: > > > > > > Thanks for the pointer. The problem appears to be /usr/local/bin/ld. > > > If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, > > > I can build math/lapack without a problem. I guess I'll poke around > > > in devel/bintuils. > > > > We don?t support building the tree with any ld but the one in the tree. > > In tree builds with the system ld does not work. That is the topic of > the first email in this thread. The issue with /usr/local/bin/ld was > found after I disabled the attempted build of ncurses. The /usr/local/bin/ld > issue surfaces when one tries to build math/lapack with shared library > support. > > % rm -rf /usr/obj/usr > % cd /usr/src > % make clean && make cleandepend > % cd lib > % make depend > % make |& tee sgk.log > ... > ===> ncurses/ncursesw (all) > Warning: Object directory not changed from original > /usr/src/lib/ncurses/ncursesw > ... > nm: 'codes.So': No such file > nm: 'expanded.So': No such file > (146 nm: lines deleted) > cc: error: no such file or directory: 'termcap.So' > cc: error: no such file or directory: 'visbuf.So' > (142 cc: lines deleted) > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src/lib/ncurses/ncursesw > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src/lib/ncurses > *** Error code 1 > > Stop. > make: stopped in /usr/src/lib > > As noted in the first email, both libncurses.a and libncurses_p.a build fine. > It looks like this is a SUBDIR_PARALLEL build fallout. I've finally committed the fine-grained dependency fix I've been sitting on for weeks, could you please try updating to r267511 and then applying the attached to see if it fixes it? -- Ian Index: lib/ncurses/Makefile === --- lib/ncurses/Makefile (revision 267508) +++ lib/ncurses/Makefile (working copy) @@ -3,4 +3,12 @@ SUBDIR= ncurses form menu panel \ ncursesw formw menuw panelw +SUBDIR_DEPEND_form= ncurses +SUBDIR_DEPEND_menu= ncurses +SUBDIR_DEPEND_panel= ncurses +SUBDIR_DEPEND_ncursesw= ncurses +SUBDIR_DEPEND_formw= ncursesw +SUBDIR_DEPEND_menuw= ncursesw +SUBDIR_DEPEND_panelw= ncursesw + .include ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 07:44:29PM -0600, Warner Losh wrote: > On Jun 14, 2014, at 7:30 PM, Steve Kargl > wrote: > > > > Thanks for the pointer. The problem appears to be /usr/local/bin/ld. > > If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, > > I can build math/lapack without a problem. I guess I'll poke around > > in devel/bintuils. > > We don?t support building the tree with any ld but the one in the tree. In tree builds with the system ld does not work. That is the topic of the first email in this thread. The issue with /usr/local/bin/ld was found after I disabled the attempted build of ncurses. The /usr/local/bin/ld issue surfaces when one tries to build math/lapack with shared library support. % rm -rf /usr/obj/usr % cd /usr/src % make clean && make cleandepend % cd lib % make depend % make |& tee sgk.log ... ===> ncurses/ncursesw (all) Warning: Object directory not changed from original /usr/src/lib/ncurses/ncursesw ... nm: 'codes.So': No such file nm: 'expanded.So': No such file (146 nm: lines deleted) cc: error: no such file or directory: 'termcap.So' cc: error: no such file or directory: 'visbuf.So' (142 cc: lines deleted) *** Error code 1 Stop. make[2]: stopped in /usr/src/lib/ncurses/ncursesw *** Error code 1 Stop. make[1]: stopped in /usr/src/lib/ncurses *** Error code 1 Stop. make: stopped in /usr/src/lib As noted in the first email, both libncurses.a and libncurses_p.a build fine. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 9:30 PM, Steve Kargl wrote: > Thanks for the pointer. The problem appears to be /usr/local/bin/ld. > If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, > I can build math/lapack without a problem. I guess I'll poke around > in devel/bintuils. I would see what changes have been made to the linker scripts that ld is using for FreeBSD. Several years ago I ran into a problem when building kld modules with an out-of-tree toolchain and the root cause ended up being that the linker scripts were broken and no longer provided a necessary symbol. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Jun 14, 2014, at 7:30 PM, Steve Kargl wrote: > On Sat, Jun 14, 2014 at 03:38:58PM -0700, Peter Wemm wrote: >> On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: >>> On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: > On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: >> >> Is it possible to using profiling on FreeBSD-current? After >> installing >> libc_p.a, I try to build math/lapack. It dies with >> >> /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to >> symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from >> command line collect2: error: ld returned 1 exit status >> *** Error code 1 > > collect2? I think you've got something odd going on there.. Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. >>> >>> Where is the symbol _end suppose to come from? >>> >>> Script started on Sat Jun 14 15:26:08 2014 >>> laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) >>> foreach? echo $i >>> foreach? nm $i | grep 'U _end' >>> foreach? nm $i | grep 'T _end' >>> foreach? end >>> /usr/lib/libc.a >>> U _end >> >> _end is a dynamic symbol that is synthesized by ld or linker scripts. >> Normally that would be /usr/bin/ld >> >> peter@hub[10:35pm]~-110> grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x >> ... >> _end. Align after .bss to ensure correct alignment even if the >> _end = .; PROVIDE (end = .); >> >> It used to be built into the a.out linker, but it's in the built-in linker >> scripts since the ELF switch. >> >> Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a >> linker >> script the gfortran stuff is using. >> > > Thanks for the pointer. The problem appears to be /usr/local/bin/ld. > If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, > I can build math/lapack without a problem. I guess I'll poke around > in devel/bintuils. We don’t support building the tree with any ld but the one in the tree. However, having said that, if you can fix it, that would be awesome. I’d like to see our support expand to include latter-day versions of binutils on all platforms to help with the eventual demise of in-tree gcc... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 03:38:58PM -0700, Peter Wemm wrote: > On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: > > On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: > > > On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: > > > > On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: > > > > > > > > > > Is it possible to using profiling on FreeBSD-current? After > > > > > installing > > > > > libc_p.a, I try to build math/lapack. It dies with > > > > > > > > > > /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to > > > > > symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from > > > > > command line collect2: error: ld returned 1 exit status > > > > > *** Error code 1 > > > > > > > > collect2? I think you've got something odd going on there.. > > > > > > Maybe. math/lapack is built with gfortran, which is from > > > lang/gcc47 on my system. lang/gcc47 is probably picking > > > up the installed devel/binutils. This would explain the > > > /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is > > > built with clang, so I'm probably running into yet-another > > > clang vs gcc problem. > > > > Where is the symbol _end suppose to come from? > > > > Script started on Sat Jun 14 15:26:08 2014 > > laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) > > foreach? echo $i > > foreach? nm $i | grep 'U _end' > > foreach? nm $i | grep 'T _end' > > foreach? end > > /usr/lib/libc.a > > U _end > > _end is a dynamic symbol that is synthesized by ld or linker scripts. > Normally that would be /usr/bin/ld > > peter@hub[10:35pm]~-110> grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x > ... > _end. Align after .bss to ensure correct alignment even if the > _end = .; PROVIDE (end = .); > > It used to be built into the a.out linker, but it's in the built-in linker > scripts since the ELF switch. > > Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker > script the gfortran stuff is using. > Thanks for the pointer. The problem appears to be /usr/local/bin/ld. If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, I can build math/lapack without a problem. I guess I'll poke around in devel/bintuils. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: > On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: > > On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: > > > On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: > > > > On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: > > > > > Long story short. I have laptop that is normally limited in > > > > > available diskspace, so I do not install profiled libraries. > > > > > I however have the need for running some code under the profiler > > > > > (assuming clang can generate proper profiling). I do the > > > > > following, > > > > > > > > Is it possible to using profiling on FreeBSD-current? After > > > > installing > > > > libc_p.a, I try to build math/lapack. It dies with > > > > > > > > /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to > > > > symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from > > > > command line collect2: error: ld returned 1 exit status > > > > *** Error code 1 > > > > > > collect2? I think you've got something odd going on there.. > > > > Maybe. math/lapack is built with gfortran, which is from > > lang/gcc47 on my system. lang/gcc47 is probably picking > > up the installed devel/binutils. This would explain the > > /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is > > built with clang, so I'm probably running into yet-another > > clang vs gcc problem. > > Where is the symbol _end suppose to come from? > > Script started on Sat Jun 14 15:26:08 2014 > laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) > foreach? echo $i > foreach? nm $i | grep 'U _end' > foreach? nm $i | grep 'T _end' > foreach? end > /usr/lib/libc.a > U _end _end is a dynamic symbol that is synthesized by ld or linker scripts. Normally that would be /usr/bin/ld peter@hub[10:35pm]~-110> grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x ... _end. Align after .bss to ensure correct alignment even if the _end = .; PROVIDE (end = .); It used to be built into the a.out linker, but it's in the built-in linker scripts since the ELF switch. Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker script the gfortran stuff is using. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: > On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: > > On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: > > > On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: > > > > Long story short. I have laptop that is normally limited in > > > > available diskspace, so I do not install profiled libraries. > > > > I however have the need for running some code under the profiler > > > > (assuming clang can generate proper profiling). I do the > > > > following, > > > > > > Is it possible to using profiling on FreeBSD-current? After installing > > > libc_p.a, I try to build math/lapack. It dies with > > > > > > /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to > > > symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from > > > command line collect2: error: ld returned 1 exit status > > > *** Error code 1 > > > > collect2? I think you've got something odd going on there.. > > > > Maybe. math/lapack is built with gfortran, which is from > lang/gcc47 on my system. lang/gcc47 is probably picking > up the installed devel/binutils. This would explain the > /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is > built with clang, so I'm probably running into yet-another > clang vs gcc problem. > Where is the symbol _end suppose to come from? Script started on Sat Jun 14 15:26:08 2014 laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) foreach? echo $i foreach? nm $i | grep 'U _end' foreach? nm $i | grep 'T _end' foreach? end /usr/lib/libc.a U _end U _endnetdnsent U _endnethtent U _endhostdnsent U _endhosthtent 0050 T _endnethtent 0ac0 T _endnetdnsent 0050 T _endhosthtent 1220 T _endhostdnsent /usr/lib/libc_p.a U _end U _endnetdnsent U _endnethtent U _endhostdnsent U _endhosthtent 0050 T _endnethtent 0b00 T _endnetdnsent 0050 T _endhosthtent 12e0 T _endhostdnsent /usr/lib/libc_pic.a U _endhostdnsent U _endhosthtent U _endnetdnsent U _endnethtent U _end 1470 T _endhostdnsent 0060 T _endhosthtent 0ba0 T _endnetdnsent 0060 T _endnethtent Script done on Sat Jun 14 15:27:01 2014 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: > On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: > > On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: > > > Long story short. I have laptop that is normally limited in > > > available diskspace, so I do not install profiled libraries. > > > I however have the need for running some code under the profiler > > > (assuming clang can generate proper profiling). I do the > > > following, > > > > Is it possible to using profiling on FreeBSD-current? After installing > > libc_p.a, I try to build math/lapack. It dies with > > > > /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to > > symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from > > command line collect2: error: ld returned 1 exit status > > *** Error code 1 > > collect2? I think you've got something odd going on there.. > Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: In tree builds broken in lib/ncurses?
On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: > On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: > > Long story short. I have laptop that is normally limited in > > available diskspace, so I do not install profiled libraries. > > I however have the need for running some code under the profiler > > (assuming clang can generate proper profiling). I do the > > following, > > Is it possible to using profiling on FreeBSD-current? After installing > libc_p.a, I try to build math/lapack. It dies with > > /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to > symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from > command line collect2: error: ld returned 1 exit status > *** Error code 1 collect2? I think you've got something odd going on there.. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: > Long story short. I have laptop that is normally limited in > available diskspace, so I do not install profiled libraries. > I however have the need for running some code under the profiler > (assuming clang can generate proper profiling). I do the > following, Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 Stop. make[3]: stopped in /usr/ports/math/lapack/work/lapack-3.4.2_PROFILE/INSTALL *** Error code 1 Stop. make[2]: stopped in /usr/ports/math/lapack/work/lapack-3.4.2_PROFILE *** Error code 1 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
In tree builds broken in lib/ncurses?
Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, % vi /etc/src.conf (Remove WITHOUT_PROFILE) % cd /usr/src % make clean % make cleandepend % cd lib % make depend % make The build dies in lib/ncurses with the following message. building shared library libncursesw.so.8 nm: 'codes.So': No such file nm: 'expanded.So': No such file nm: 'fallback.So': No such file nm: 'lib_gen.So': No such file ... cc: error: no such file or directory: 'termcap.So' cc: error: no such file or directory: 'visbuf.So' cc: error: no such file or directory: 'lib_trace.So' ... cc: error: no such file or directory: 'codes.So' *** Error code 1 Stop. make[1]: stopped in /usr/src/lib/ncurses/ncursesw *** Error code 1 Stop. make: stopped in /usr/src/lib/ncurses Amusingly, both libncurses.a and libncurses_p.a are built just fine. Is there any chance that in-tree builds will work as they once did? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
