http://blog.gmane.org/gmane.os.netbsd.devel.toolchain hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5449 <pre>Back in 2000, the callpath through Suff_FindDeps was skipped for .PHONY targets. It turns out though that that is the only place where wildcard targets are expanded. Assuming there is something in ./sub/ the makefile: .MAIN: all all: subs SUBS= sub/* subs:${SUBS} &lt; at &gt;echo yay ${SUBS} .ifdef PHONY .PHONY: subs .endif works so long as PHONY isn't defined. The patch below (sans fixing the indentation) pushes the PHONY check lower so that wildcards can be expanded correctly, while still skipping most of the suffix related effort. Index: suff.c =================================================================== RCS file: /cvsroot/src/usr.bin/make/suff.c,v retrieving revision 1.69 diff -u -p -r1.69 suff.c --- suff.c29 Sep 2011 23:38:04 -00001.69 +++ suff.c16 May 2013 18:34:29 -0000 &lt; at &gt;&lt; at &gt; -2058,6 +2058,10 &lt; at &gt;&lt; at &gt; SuffFindNormalDeps(GNode *gn, Lst slst) * children, then look for any overriding transformations they imply. * Should we find one, we discard the one we found before. */ + bottom = NULL; + targ = NULL; + + if (!(gn-&gt;type &amp; OP_PHONY)) { while (ln != NULL) { /* &lt; at &gt;&lt; at &gt; -2171,6 +2175,7 &lt; at &gt;&lt; at &gt; SuffFindNormalDeps(GNode *gn, Lst slst) for (targ = bottom; targ-&gt;parent != NULL; targ = targ-&gt;parent) continue; } + } Var_Set(TARGET, gn-&gt;path ? gn-&gt;path : gn-&gt;name, gn, 0); &lt; at &gt;&lt; at &gt; -2419,12 +2424,7 &lt; at &gt;&lt; at &gt; SuffFindDeps(GNode *gn, Lst slst) */ Var_Set(TARGET, gn-&gt;path ? gn-&gt;path : gn-&gt;name, gn, 0); Var_Set(PREFIX, gn-&gt;name, gn, 0); - if (gn-&gt;type &amp; OP_PHONY) { -/* - * If this is a .PHONY target, we do not apply suffix rules. - */ -return; - } + if (DEBUG(SUFF)) { fprintf(debug_file, "SuffFindDeps (%s)\n", gn-&gt;name); } </pre> Simon Gerraty 2013-05-16T18:40:25 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5447 <pre>Hi When I build netbsd-6 using build.sh -Uuom i386 release, I get an error because of missing src/distrib/i386/ramdisks/ramdisk-big/sysinst/sysinstmsgs.es Other sysinstmsgs.* are missing as well. Is there anything wrong with that build.sh usage? </pre> Emmanuel Dreyfus 2013-03-25T17:45:58 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5443 <pre>Running an unpriviledged build of a current netbsd-6 source tree fails with ====== 3 missing files in DESTDIR ======== Files in flist but missing from DESTDIR. File wasn't installed ? ------------------------------------------ ./usr/share/zoneinfo/Asia/Khandyga ./usr/share/zoneinfo/Asia/Ust-Nera ./usr/share/zoneinfo/Europe/Busingen ======== end of 3 missing files ========== *** [checkflist] Error code 1 I'm not sure whether this is the right place to report this. </pre> Edgar Fuß 2013-03-15T20:49:34 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5440 <pre> Hi, While trying to update my -current amd64 workstation, i luckily found a non-fatal(?) error while early building binstall ... dependall ===&gt; binstall create binstall/getid.d create binstall/xinstall.d In file included from /local/src/NetBSD/src/tools/binstall/../../usr.bin/xinstall/xinstall.c:77:0: /local/src/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: fatal error: nbtool_config.h: No such file or directory compilation terminated. create binstall/.depend compile binstall/xinstall.lo compile binstall/getid.lo link binstall/xinstall xinstall.lo: In function `do_symlink': xinstall.c:(.text+0x604): warning: warning: mktemp() possibly used unsafely,use mkstemp() or mkdtemp() Looks like host_mkdep tool does not return a non zero status upon error, letting build continue : # create binstall/xinstall.d /local/src/NetBSD/src/tools/host-mkdep/obj.amd64/host-mkdep -f xinstall.d -- -I/local/src/NetBSD/src/tools/binstall/../compat/sys -DTARGET_STRIP=\"/local/src/NetBSD/tool/bin/x86_64--netbsd-strip\"-I/local/src/NetBSD/src/usr.sbin/mtree /local/src/NetBSD/src/tools/binstall/../../usr.bin/xinstall/xinstall.c In file included from /local/src/NetBSD/src/tools/binstall/../../usr.bin/xinstall/xinstall.c:77:0: /local/src/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: fatal error: nbtool_config.h: No such file or directory compilation terminated. # create binstall/.depend rm -f .depend /local/src/NetBSD/src/tools/host-mkdep/obj.amd64/host-mkdep -s .lo\ .ln -d -f .depend getid.d xinstall.d [...] Any idea how to correctly fix this one ... I'm not a shell expert. This problem arise when C preprocessor fails, but the error seems lost because the of the pipe to an awk command. Thanks. </pre> Nicolas Joly 2013-03-11T19:54:17 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5427 <pre>Hi, To make a long story short, the following definitions of posix_memalign() seem to conflict in pedantic g++ mode, on a stock NetBSD-6.0.1/amd64: In /usr/include/gcc-4.5/mm_malloc.h: extern "C" int posix_memalign (void **, size_t, size_t) throw (); In /usr/include/stdlib.h: int posix_memalign(void **, size_t, size_t); Not sure who to blame here :) Should I open a PR for this, or is this more a gcc issue? Here is how to reproduce the problem: fluffy64-netbsd6[~] &gt; cat mm_malloc.c #include &lt;xmmintrin.h&gt; int main() { return 0; } fluffy64-netbsd6[~] &gt; g++ -pedantic ~/mm_malloc.c In file included from /usr/include/gcc-4.5/xmmintrin.h:39:0, from /home/mallet/mm_malloc.c:1: /usr/include/gcc-4.5/mm_malloc.h:34:64: error: declaration of 'int posix_memalign(void**, size_t, size_t) throw ()' throws different exceptions /usr/include/stdlib.h:237:6: error: from previous declaration 'int posix_memalign(void**, size_t, size_t)' </pre> Anthony Mallet 2013-03-09T15:14:56 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5414 <pre>Is there a sane way to have target A built before target B without having B depend on A? Is .ORDER A B guaranteed to do that? The description of .ORDER says "The ordering imposed by .ORDER is only relevant for parallel makes." Does that mean it only imposes the ordering restrictions for parallel makes or the author of the manpage couldn't think of an example other that parallel makes where you will want a particular order without a dependency? In my case, A is a directory containing B. The rules for A install -d and the rules for B install /dev/null. With B depending on A, B will be wiped out whenever you touch another file in directory A. Probably there's a more elegant way to acheive the same thing. </pre> Edgar Fuß 2013-01-22T17:00:11 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5412 <pre>I added the Check_Cwd_av logic at least 10 years ago, to avoid the need to fix lots of makefiles which didn't work with MAKEOBJDIRPREFIX. I suspect the need for it has passed. Building with separate obj trees (via MAKEOBJDIRPREFIX etc), seems almost universal now. Perhaps it is time to retire this check or perhaps disable it by default? Anyway, the patch below teaches it to spot 'make -C somewhere' as the equivalent of 'cd somewhere &amp;&amp; make'. I limited the check of make args to some small number, since I at least tend to make -C one of the 1st args, and it is rare that an extra 'cd ${.CURDIR}' will do harm. Setting MAKE_CHECK_CWD_ARGS to 0 would check them all. --sjg Index: main.c =================================================================== RCS file: /cvsroot/src/usr.bin/make/main.c,v retrieving revision 1.203 diff -u -p -r1.203 main.c --- main.c31 Aug 2012 07:00:36 -00001.203 +++ main.c18 Jan 2013 17:58:02 -0000 &lt; at &gt;&lt; at &gt; -1406,6 +1406,11 &lt; at &gt;&lt; at &gt; found: */ static int Check_Cwd_Off = 0; +/* Limit the number of args to make we check for -C */ +#ifndef MAKE_CHECK_CWD_ARGS +# define MAKE_CHECK_CWD_ARGS 8 +#endif + static char * Check_Cwd_av(int ac, char **av, int copy) { &lt; at &gt;&lt; at &gt; -1413,6 +1418,8 &lt; at &gt;&lt; at &gt; Check_Cwd_av(int ac, char **av, int copy static char *cur_dir = NULL; char **mp; char *cp; + char *is_make; + int check_args; int is_cmd, next_cmd; int i; int n; &lt; at &gt;&lt; at &gt; -1453,7 +1460,8 &lt; at &gt;&lt; at &gt; Check_Cwd_av(int ac, char **av, int copy return NULL; } - + is_make = NULL; + check_args = MAKE_CHECK_CWD_ARGS; next_cmd = 1; for (i = 0; i &lt; ac; ++i) { is_cmd = next_cmd; &lt; at &gt;&lt; at &gt; -1461,9 +1469,13 &lt; at &gt;&lt; at &gt; Check_Cwd_av(int ac, char **av, int copy n = strlen(av[i]); cp = &amp;(av[i])[n - 1]; if (strspn(av[i], "|&amp;;") == (size_t)n) { + if (is_make) +break; next_cmd = 1; continue; } else if (*cp == ';' || *cp == '&amp;' || *cp == '|' || *cp == ')') { + if (is_make) +break; next_cmd = 1; if (copy) { do { &lt; at &gt;&lt; at &gt; -1507,16 +1519,33 &lt; at &gt;&lt; at &gt; Check_Cwd_av(int ac, char **av, int copy for (mp = make; *mp != NULL; ++mp) { n = strlen(*mp); if (strcmp(cp, *mp) == 0) { - if (DEBUG(CWD)) -fprintf(debug_file, " %s == '%s', chdir(%s)\n", - cp, *mp, cur_dir); - return cur_dir; + is_make = *mp; + break; } } +} else if (is_make) { + /* looking at args to make */ + if (strcmp("-C", cp) == 0) { +if (DEBUG(CWD)) + fprintf(debug_file, " == cd, done.\n"); +return NULL; + } + if (MAKE_CHECK_CWD_ARGS &gt; 0 &amp;&amp; check_args-- &lt;= 0) { +/* -C is usually one of the first args? give up now */ +if (DEBUG(CWD)) + fprintf(debug_file, "\n"); +break; + } } if (DEBUG(CWD)) fprintf(debug_file, "\n"); } + if (is_make) { +if (DEBUG(CWD)) + fprintf(debug_file, "cmd == '%s', chdir(%s)\n", + is_make, cur_dir); +return cur_dir; + } return NULL; } </pre> Simon Gerraty 2013-01-18T18:01:25 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5403 <pre> I'm trying a crossbuild of NetBSD-current/amd64 on a NetBSD 6.0/i386 host, and get: ... ===&gt; Bootstrapping nbmake checking for sh... /bin/sh checking for gcc... cc checking for C compiler default output... configure: error: C compiler cannot create executables ERROR: Configure of nbmake failed *** BUILD ABORTED *** Not very useful. Digging and chopping to get at config.log (and ignoring what the error for this was, for a second), I wonder if we should print the nbmake configure's config.log if we detect an error. The patch below does this for me. Any comments? - Hubert Index: build.sh =================================================================== RCS file: /cvsroot/src/build.sh,v retrieving revision 1.260 diff -u -r1.260 build.sh --- build.sh 2 Dec 2012 19:19:36 -0000 1.260 +++ build.sh 13 Jan 2013 00:15:07 -0000 &lt; at &gt;&lt; at &gt; -1454,7 +1454,9 &lt; at &gt;&lt; at &gt; ${runcmd} env CC="${HOST_CC-cc}" CPPFLAGS="${HOST_CPPFLAGS}" \ CFLAGS="${HOST_CFLAGS--O}" LDFLAGS="${HOST_LDFLAGS}" \ ${HOST_SH} "${TOP}/tools/make/configure" || - bomb "Configure of ${toolprefix}make failed" + ( echo Contents of ${tmpdir}/config.log: ; + cat ${tmpdir}/config.log ; + bomb "Configure of ${toolprefix}make failed" ) ${runcmd} ${HOST_SH} buildmake.sh || bomb "Build of ${toolprefix}make failed" make="${tmpdir}/${toolprefix}make" </pre> Hubert Feyrer 2013-01-13T00:27:31 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5401 <pre>Hi! When linking a shared library with libtool against libfl.a it complains: *** Warning: linker path does not have real file for library -lfl. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libfl and none of the candidates passed a file format test *** using a regex pattern. Last file checked: /usr/lib/libfl.a Is there a reason we don't provide a libfl.so? Or should I call libtool differently? Thomas </pre> Thomas Klausner 2013-01-12T17:52:47 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5393 <pre>Is anyone able to run any variant of mknative in -current? It seems broken to me, maybe due to the recent tool/objdir changes? When calling the "getvars" shell function it passes a relative name of a Makefile to the function, which then seems to resolve that locally to some directory deep inside $OBJDIR, but there (of course) no makefile of that name exists. Martin </pre> Martin Husemann 2012-12-15T13:09:08 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5383 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I use to include my GNU/Linux machines CPUs when building packages by using distcc. I build the toolchain the standard way: $ ./build.sh -j4 -m amd64 -T /home/netbsd/tools tools This worked OOB until I upgraded some of my NetBSD machines to NetBSD 6.0. I then upgraded the toolchain in the Linux machine to -rnetbsd-6-0, but distcc stopped working. Digging a little bit, I discovered that gcc was failing because it couldn't find `cc1'. `cc1' is located here: tools/libexec/gcc/x86_64--netbsd/4.5.3/cc1 whereas: $ tools/x86_64--netbsd/bin/gcc -print-search-dirs install: /home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/x86_64--netbsd/4.5.3/ programs: =/home/netbsd/tools/x86_64--netbsd/bin/../libexec/gcc/x86_64--netbsd/4.5.3/:/home/netbsd/tools/x86_64--netbsd/bin/../libexec/gcc/:/home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/x86_64--netbsd/4.5.3/../../../../x86_64--netbsd/bin/x86_64--netbsd/4.5.3/:/home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/x86_64--netbsd/4.5.3/../../../../x86_64--netbsd/bin/ libraries: =/home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/x86_64--netbsd/4.5.3/:/home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/:/home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/x86_64--netbsd/4.5.3/../../../../x86_64--netbsd/lib/x86_64--netbsd/4.5.3/:/home/netbsd/tools/x86_64--netbsd/bin/../lib/gcc/x86_64--netbsd/4.5.3/../../../../x86_64--netbsd/lib/ Adding a symlink in tools/x86_64--netbsd/ did the trick: lrwxrwxrwx 1 root root 10 Dec 11 17:49 tools/x86_64--netbsd/libexec -&gt; ../libexec But as this used to work before, I presume something broke. Is this worth a PR? Thanks, - ------------------------------------------------------------------ Emile "iMil" Heitor .°. &lt;imil&lt; at &gt;{home.imil.net,NetBSD.org,gcu.info}&gt; _ | http://imil.net | ASCII ribbon campaign ( ) | http://www.NetBSD.org | - against HTML email X | http://gcu.info | &amp; vCards / \ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (NetBSD) iD8DBQFQx3srFG3BlGWyzUIRAmpfAJ9kLWzPNuk2ODoWDhVdYtpQJa9QpACdElgt YvDJVxyw4WW1irYGnuhftsc= =RXTf -----END PGP SIGNATURE----- </pre> iMil 2012-12-11T18:27:55 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5380 <pre>Hi, For ages it was possible to use the same obj directory for multiple architecture builds when using build.sh. Sometime between netbsd-5 and netbsd-6, this broke. It seems that the same directory is used for all architectures: objdir/external/lgpl3/gmp/lib/libgmp/ This causes libgmp to fail like this: --- lshift.o --- # compile libgmp/lshift.o /usr/src/../tools/bin/arm--netbsdelf-gcc -fPIC -Wno-stack-protector -c lshift.s -o lshift.o lshift.s: Assembler messages: lshift.s:75: Error: unrecognized symbol type "" lshift.s:78: Error: bad instruction `moveml %d2-%d6/%a2,%sp' lshift.s:81: Error: bad instruction `movel %sp' lshift.s:82: Error: bad instruction `movel %sp' lshift.s:83: Error: bad instruction `movel %sp' lshift.s:84: Error: bad instruction `movel %sp' lshift.s:86: Error: bad instruction `moveql #1,%d5' lshift.s:87: Error: bad instruction `cmpw %d5,%d4' lshift.s:88: Error: bad instruction `jne .LLnormal' lshift.s:89: Error: bad instruction `cmpl %a0,%a1' lshift.s:90: Error: bad instruction `jls .LLspecial' lshift.s:93: Error: bad instruction `movel %d6,%d0' lshift.s:94: Error: bad instruction `asll #2,%d0' lshift.s:95: Error: bad instruction `lea %a0' lshift.s:97: Error: bad instruction `cmpl %a1,%a2' lshift.s:98: Error: bad instruction `jls .LLspecial' lshift.s:101: Error: bad instruction `moveql #32,%d5' lshift.s:102: Error: bad instruction `subl %d4,%d5' lshift.s:105: Error: bad instruction `movel %d6,%d0' lshift.s:106: Error: bad instruction `asll #2,%d0' lshift.s:107: Error: bad instruction `addl %d0,%a0' lshift.s:108: Error: bad instruction `addl %d0,%a1' lshift.s:110: Error: bad instruction `movel %a0' lshift.s:111: Error: bad instruction `movel %d2,%d0' lshift.s:112: Error: bad instruction `lsrl %d5,%d0' lshift.s:114: Error: bad instruction `lsll %d4,%d2' lshift.s:115: Error: bad instruction `movel %d2,%d1' lshift.s:116: Error: bad instruction `subql #1,%d6' lshift.s:117: Error: bad instruction `jeq .LLend' lshift.s:118: Error: bad instruction `lsrl #1,%d6' lshift.s:119: Error: bad instruction `jcs .LL1' lshift.s:120: Error: bad instruction `subql #1,%d6' lshift.s:123: Error: bad instruction `movel %a0' lshift.s:124: Error: bad instruction `movel %d2,%d3' lshift.s:125: Error: bad instruction `lsrl %d5,%d3' lshift.s:126: Error: bad instruction `orl %d3,%d1' lshift.s:127: Error: bad instruction `movel %d1,%a1' lshift.s:128: Error: bad instruction `lsll %d4,%d2' lshift.s:130: Error: bad instruction `movel %a0' lshift.s:131: Error: bad instruction `movel %d1,%d3' lshift.s:132: Error: bad instruction `lsrl %d5,%d3' lshift.s:133: Error: bad instruction `orl %d3,%d2' lshift.s:134: Error: bad instruction `movel %d2,%a1' lshift.s:135: Error: bad instruction `lsll %d4,%d1' lshift.s:137: Error: bad instruction `dbf %d6,.LLoop' lshift.s:138: Error: bad instruction `subl #0x10000,%d6' lshift.s:139: Error: bad instruction `jcc .LLoop' lshift.s:142: Error: bad instruction `movel %d1,%a1' lshift.s:145: Error: bad instruction `moveml %sp' lshift.s:146: Error: bad instruction `rts' lshift.s:153: Error: bad instruction `clrl %d0' lshift.s:154: Error: bad instruction `eorw #1,%d6' lshift.s:155: Error: bad instruction `lsrl #1,%d6' lshift.s:156: Error: bad instruction `jcc .LLL1' lshift.s:157: Error: bad instruction `subql #1,%d6' lshift.s:160: Error: bad instruction `movel %a0' lshift.s:161: Error: bad instruction `addxl %d2,%d2' lshift.s:162: Error: bad instruction `movel %d2,%a1' lshift.s:164: Error: bad instruction `movel %a0' lshift.s:165: Error: bad instruction `addxl %d2,%d2' lshift.s:166: Error: bad instruction `movel %d2,%a1' lshift.s:168: Error: bad instruction `dbf %d6,.LLLoop' lshift.s:169: Error: bad instruction `addxl %d0,%d0' lshift.s:170: Error: bad instruction `subl #0x10000,%d6' lshift.s:171: Error: bad instruction `jcs .LLLend' lshift.s:172: Error: bad instruction `lsrl #1,%d0' lshift.s:173: Error: bad instruction `jra .LLLoop' lshift.s:177: Error: bad instruction `moveml %sp' lshift.s:178: Error: bad instruction `rts' *** [lshift.o] Error code 1 nbmake: stopped in /usr/src/external/lgpl3/gmp/lib/libgmp Thoughts? John </pre> John Klos 2012-11-22T23:31:22 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5378 <pre>FreeBSD switched its i386 and amd64 ports to clang as default compiler. http://lists.freebsd.org/pipermail/freebsd-current/2012-November/037458.html What's the plan for NetBSD? Thomas </pre> Thomas Klausner 2012-11-05T23:18:04 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5370 <pre>Hi, I'm trying to get gdb to crossbuild for evbppc. I've set MKCROSSGDB (build.sh -V MKCROSSGDB=yes ...) but get the following errors: src/tools/gdb/../../external/gpl3/gdb/dist/sim/ppc/emul_netbsd.c: In function 'do_gettimeofday': src/tools/gdb/../../external/gpl3/gdb/dist/sim/ppc/emul_netbsd.c:741: error: 'SYS___gettimeofday50' undeclared (first use in this function) src/tools/gdb/../../external/gpl3/gdb/dist/sim/ppc/emul_netbsd.c:741: error: (Each undeclared identifier is reported only once src/tools/gdb/../../external/gpl3/gdb/dist/sim/ppc/emul_netbsd.c:741: error: for each function it appears in.) src/tools/gdb/../../external/gpl3/gdb/dist/sim/ppc/emul_netbsd.c: In function 'do_getrusage': src/tools/gdb/../../external/gpl3/gdb/dist/sim/ppc/emul_netbsd.c:771: error: 'SYS___getrusage50' undeclared (first use in this function) Looking further at how gcc builds find but gdb fails I find the two directories: gnu/dist/gdb6/sim/ppc used for building gcc external/gpl3/gdb/dist/sim/ppc for building gdb have identical READMEs (PSIM 1.0.1 - Model of the PowerPC Environments) but the gdb6 ChangeLog show lots of updates since the gpl3/gdb directory. Is this the problem ? Thanks </pre> Martin L Resnick 2012-10-09T12:03:17 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5369 <pre>The problem that leads to a successful but broken build is that libssl ends up linked to the old libcrypto instead of the new one. Then all (or nearly all) binaries end up linked to both versions of libcrypto and subsequent behavior is undefined. Anyhow, I just found the bug in the makefiles that causes this. In lib/Makefile we (now) have the following logic: build_install: .for group in ${SUBDIR_GROUPS} . if !empty(SUBDIR_GROUP.${group}) ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${group}:C/^/dependall-/} ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${group}:C/^/install-/} . endif .endfor This is what's run during the lib phase of a full build. The problem is that libcrypto and libssl do not appear separately in this file; all that appears in this file is ../crypto/external/bsd/openssl/lib. Therefore, during a build, what happens is... first we make dependall in openssl/lib, which first makes libcrypto and then dutifully waits before making libssl. Then we make install in openssl/lib, at which point the new libcrypto is placed in $DESTDIR. Unfortunately, libssl has at this point already been linked to the old libcrypto in $DESTDIR; and the barrier implicit in recursing twice in the logic pasted above is what makes the failure deterministic. If you clean out $DESTDIR, then this can't happen. I'm not sure why the build doesn't simply fail at this point due to there being no libcrypto to link to; maybe it's capable of finding the lib in the libcrypto build dir but prefers the one in $DESTDIR if present. Or maybe it just charges ahead; ELF toolchains believe by default that you don't need to resolve symbols successfully when building libraries and I'm not sure how thoroughly we disable that misfeature. Anyway, either lib/Makefile needs to know about the various openssl libraries individually, or this dodgy build_install rule needs to be fixed/removed. Why does it have its own private recursion logic again? </pre> David Holland 2012-10-08T05:39:26 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5366 <pre>Hi. I wane add elftosb as a tool to the NetBSD tool chain. Elftosb is needed to prepare ELF executables for booting on a Freescale i.MX23 application processor. I.e. It converts the ELF file format into a special "sb" file format that the in-chip-ROM first stage bootloader can read and execute. elftosb is a package that contains three programms (elftosb, sbtool and sbkeygen) and a static library used by these three programms. It comes with simple Makefiles, no autoconf or the like. I imported elftosb into src/external/bsd/elftosb and can (cross) build the three programms as target programms. But how to add this as a tool? I had a look at various Makefiles below src/tools. Adding a single programm without a lib is trivial. More complex programms that add several executabels like binutils use some autoconf magic. pkg_install does somthing in the way I need, but it is unused and suffers from bitrot. Doing somthing sililar like pkg_install results in: [jkunz&lt; at &gt;MissSophie elftosb]$ nbmake-evbarm obj obj ===&gt; lib cd: can't cd to /datengrab/src/NetBSD/current/src/tools/elftosb/lib/../compat Note: I have never done any NetBSD userland hacking before. So I am quite unfamilar with the userland makefile infrastructure. /usr/share/mk/bsd.README didn't get me much enlightening either about building tools. </pre> Jochen Kunz 2012-10-06T16:49:53 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5361 <pre>Hello, The attached patch adds documentation for the following build knobs to the mk.conf(5) manual page: EXTSRCSRCDIR, MKARZERO, MKBSDTAR, MKCLEANSRC, MKCLEANVERIFY, MKCOMPAT, MKDTRACE, MKEXTSRC, MKLVM, MKMANDOC, MKNPF, MKPIGZGZIP, MKREPRO, MKRUMP, MKX11FONTS and MKZFS. Could you please review? </pre> Joseph Koshy 2012-09-29T14:30:44 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5345 <pre>Hi there! IRC nick on freenode #NetBSD: Alba This is my first mail, apologizes if i unintentionally skipped some formality or some process. Thanks in advance! But the least I think I could do now is describe how did I come up with the following error. 1. I downloaded NetBSD 5.1.2 2. I ran Ubuntu 12.04 3. After that, I extracted NetBSD 5.1.2 4. From the errors I got during configuration phase, I did 3 things (install zlib, change permission for missing.sh to executable, install g++) 5. That allowed me to run *"sudo ./build.sh -m i386 tools"* successfully 6. With the toolchain built, I proceeded to: *31.4. Crosscompiling the kernel with build.sh* 7. After I ran "*./build.sh -u -m i386 kernel=MYKERNEL"*, I got the following error which I will continue trying to resolve tmr: *** buffer overflow detected ***: /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar terminated ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xb76eedd5] /lib/i386-linux-gnu/libc.so.6(+0xfebaa)[0xb76edbaa] /lib/i386-linux-gnu/libc.so.6(+0xfe208)[0xb76ed208] /lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0x91)[0xb7660461] /lib/i386-linux-gnu/libc.so.6(_IO_padn+0xc9)[0xb7653f79] /lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0x3282)[0xb7632a72] /lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0xc9)[0xb76ed2d9] /lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x2f)[0xb76ed1ef] /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar[0x804de56] /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar[0x804fef0] /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar[0x8056fbb] /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar[0x804aee5] /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar[0x804bfb1] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb76084d3] /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar[0x80493f1] ======= Memory map: ======== 08048000-080a9000 r-xp 00000000 08:01 3151079 /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar 080a9000-080aa000 r--p 00061000 08:01 3151079 /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar 080aa000-080ab000 rw-p 00062000 08:01 3151079 /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar 080ab000-080af000 rw-p 00000000 00:00 0 08100000-08142000 rw-p 00000000 00:00 0 [heap] b75bf000-b75db000 r-xp 00000000 08:01 8127412 /lib/i386-linux-gnu/libgcc_s.so.1 b75db000-b75dc000 r--p 0001b000 08:01 8127412 /lib/i386-linux-gnu/libgcc_s.so.1 b75dc000-b75dd000 rw-p 0001c000 08:01 8127412 /lib/i386-linux-gnu/libgcc_s.so.1 b75ee000-b75ef000 rw-p 00000000 00:00 0 b75ef000-b778e000 r-xp 00000000 08:01 8127391 /lib/i386-linux-gnu/ libc-2.15.so b778e000-b7790000 r--p 0019f000 08:01 8127391 /lib/i386-linux-gnu/ libc-2.15.so b7790000-b7791000 rw-p 001a1000 08:01 8127391 /lib/i386-linux-gnu/ libc-2.15.so b7791000-b7794000 rw-p 00000000 00:00 0 b77a4000-b77a7000 rw-p 00000000 00:00 0 b77a7000-b77a8000 r-xp 00000000 00:00 0 [vdso] b77a8000-b77c8000 r-xp 00000000 08:01 8127371 /lib/i386-linux-gnu/ ld-2.15.so b77c8000-b77c9000 r--p 0001f000 08:01 8127371 /lib/i386-linux-gnu/ ld-2.15.so b77c9000-b77ca000 rw-p 00020000 08:01 8127371 /lib/i386-linux-gnu/ ld-2.15.so bfc1c000-bfc3f000 rw-p 00000000 00:00 0 [stack] Aborted (core dumped) *** Failed target: libcompat.a *** Failed command: /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar cq libcompat.a `NM=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-nm NM=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-nm MKTEMP=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nbmktemp /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nblorder compat_exec.o compat_util.o kern_exit_43.o kern_info_43.o kern_resource_43.o kern_sig_43.o tty_43.o uipc_syscalls_43.o vfs_syscalls_43.o vm_43.o kern_info_09.o kern_xxx_12.o vfs_syscalls_12.o vm_12.o kern_sig_13.o sysv_ipc_14.o sysv_msg_14.o sysv_shm_14.o sysv_sem_14.o vfs_syscalls_20.o vfs_syscalls_30.o uipc_syscalls_30.o uipc_syscalls_40.o kern_ipc_10.o | /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nbtsort -q` *** Error code 134 Stop. nbmake: stopped in /home/jorge/netbsd/5.1.2/usr/src/sys/arch/i386/compile/obj/MYKERNEL/lib/compat *** Failed target: /home/jorge/netbsd/5.1.2/usr/src/sys/arch/i386/compile/obj/MYKERNEL/lib/compat/libcompat.a *** Failed command: cd /home/jorge/netbsd/5.1.2/usr/src/sys/arch/i386/compile/obj/MYKERNEL/lib/compat &amp;&amp; /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nbmake -f /home/jorge/netbsd/5.1.2/usr/src/sys/compat/common/Makefile COMPATDIR=/home/jorge/netbsd/5.1.2/usr/src/sys/compat/common CC=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-gcc CFLAGS=\ -ffreestanding\ -fno-zero-initialized-in-bss\ \ -O2\ -std=gnu99\ -fno-strict-aliasing\ \ \ -Werror\ -Wall\ -Wno-main\ -Wno-format-zero-length\ -Wpointer-arith\ -Wmissing-prototypes\ -Wstrict-prototypes\ -Wswitch\ -Wshadow\ -Wcast-qual\ -Wwrite-strings\ -Wno-unreachable-code\ -Wno-sign-compare\ -Wno-pointer-sign\ -Wno-attributes\ -Wextra\ -Wno-unused-parameter\ \ -Werror\ -march=i486\ -mtune=pentiumpro AS=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-as AFLAGS=\ -x\ assembler-with-cpp\ -traditional-cpp\ -D_LOCORE\ -Wa,-fatal-warnings\ \ -march=i486\ -mtune=pentiumpro AR=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ar NM=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-nm LORDER=NM=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-nm\ MKTEMP=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nbmktemp\ /home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nblorder TSORT=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/nbtsort\ -q RANLIB=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ranlib LD=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-ld STRIP=/home/jorge/netbsd/5.1.2/usr/src/tooldir.Linux-3.2.0-29-generic-pae-i686/bin/i386--netbsdelf-strip MACHINE=i386 MACHINE_ARCH=i386 COMPATCPPFLAGS=-Di386\ -I../../.\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/../common/include\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/arch\ -I/home/jorge/netbsd/5.1.2/usr/src/sys\ -nostdinc\ -DLKM\ -DMAXUSERS=64\ -D_KERNEL\ -D_KERNEL_OPT\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/lib/libkern/../../../common/lib/libc/quad\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/lib/libkern/../../../common/lib/libc/string\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/external/isc/atheros_hal/dist\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/external/isc/atheros_hal/ic\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/../common/include\ -I/home/jorge/netbsd/5.1.2/usr/src/sys/dist/ipf LINTFLAGS=-bcehnxzFS libcompat.a *** Error code 1 Stop. nbmake: stopped in /home/jorge/netbsd/5.1.2/usr/src/sys/arch/i386/compile/obj/MYKERNEL ERROR: Failed to make all in /home/jorge/netbsd/5.1.2/usr/src/sys/arch/i386/compile/obj/MYKERNEL *** BUILD ABORTED *** </pre> Jorge Yee 2012-08-22T09:47:59 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5338 <pre>Hi all, a while the compat build system was revamped to require much less magic. This leaves the interaction between src/Makefile, src/lib/Makefile and the dependencies within as the biggest ward in the current system. Attached is a patch that drops most of the magic from src/Makefile and provides a single build_install target called called in src/lib/Makefile to provide the magic. This ensures that all blocks (delimited by .WAIT) of sub directories are build and installed before the next block. This means that libraries can finally link correctly against the installed versions, removing the last big reason for leaking libstdc++ and the source locations into various Makefiles. Effectively, this would allow replacing LIBDPLIBS with a much simpler version as long as the libraries are installed first. One thing I am still contemplating is whether to make build_install a primary target in all directories or not. Joerg </pre> Joerg Sonnenberger 2012-08-11T21:27:04 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5329 <pre>If I understand the gcc folks correctly(1), a stock gcc configured and compiled on NetBSD should have -fPIC in the CRTSTUFF_T_CFLAGS variable for all archs, wich means libgcc's crstuff gets compiled with -fPIC. This is needed for -pie to work. However, our reach-over equivalent G_CRTSTUFF_T_CFLAGS does not have it for any arch(2). I guess -pie only works on i386/amd64 since by default they don't use gcc's crtstuff nowadays. I initially tried to fix it for sparc* only, but mknative fails for me and it looks like a much broader fix should be done instead. Does anyone see why we don't pick this up during mknative? Please fix and request pullup to -6 ASAP ;-) Martin (1) = http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54226 (2) = cd /usr/src/external/gpl3/gcc/lib/crtstuff/arch &amp;&amp; fgrep G_CRTSTUFF_T_CFLAGS * </pre> Martin Husemann 2012-08-11T12:46:41 http://comments.gmane.org/gmane.os.netbsd.devel.toolchain/5322 <pre>make -V is extemely useful for helping to debug and develop makefiles. By default make -V VAR outputs the Value of the variable which might a plain string, or it might be composed of other variables. To ensure VAR is fully expanded you need make -V '${VAR}' and of course you can also apply modifiers and other cool stuff. Being able to get the raw value of a variable is definitely useful, but I'm wondering if it makes a good default. 99% of the time I end up doing: make -V VAR make -V '${VAR}' So I've been wondering if it would make sense to change the ability to get the raw value into a debug option. Eg. make -dV VAR gives the raw value, while make -V VAR gives the fully expanded one. You then only need to resort to '${VAR}' when you actually want to manipulate the value. Crazy talk? --sjg </pre> Simon Gerraty 2012-08-06T23:58:20 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.devel.toolchain