01.07.2015 19:55, Denys Vlasenko wrote: > Rob Landley has an opposite view: preprocessor #if's are evil. > > I agree with him that they do tend to obfuscate.
So what's the solution to this? Blame compilers and force them to act like GCC does? Thanks, /mjt > On Sun, Jun 28, 2015 at 9:44 AM, Michael Tokarev <m...@tls.msk.ru> wrote: >> [Rehashing a thread from 3 years ago] >> >> 28.01.2013 11:48, Denys Vlasenko wrote: >>> On Monday 28 January 2013 00:17, Abdoulaye Walsimou GAYE wrote: >> >>>>>>> diff --git a/archival/libarchive/Kbuild.src >>>>>>> b/archival/libarchive/Kbuild.src >>>>>>> index 58457fc..87e1ab9 100644 >>>>>>> --- a/archival/libarchive/Kbuild.src >>>>>>> +++ b/archival/libarchive/Kbuild.src >>>>>>> -lib-$(CONFIG_TAR) += get_header_tar.o >>>>>>> +lib-$(CONFIG_TAR) += get_header_tar.o >>>>>>> decompress_uncompress.o >>>> >>>> /home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/busybox-1.20.2/archival/tar.c:1065: >>>> undefined reference to `unpack_Z_stream' >>>> /home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/busybox-1.20.2/archival/tar.c:1065: >>>> undefined reference to `unpack_Z_stream' >>>> /home/walsimou/embtoolkit.git/tools-mipsel-linux-mips32/bin/mipsisa32el-unknown-linux-uclibc-ld: >>>> busybox_unstripped: hidden symbol `unpack_Z_stream' isn't defined >>>> /home/walsimou/embtoolkit.git/tools-mipsel-linux-mips32/bin/mipsisa32el-unknown-linux-uclibc-ld: >>>> final link failed: Bad value >>>> mipsisa32el-unknown-linux-uclibc-clang: error: linker command failed with >>>> exit code 1 (use -v to see invocation) >>> >>> >>> I was able to build busybox-1.20.2 with this .config >>> without errors. >>> >>> Looks like your compiler did not optimize this out: >>> >>> if (opt & OPT_COMPRESS) >>> USE_FOR_MMU(xformer = unpack_Z_stream;) >>> USE_FOR_NOMMU(xformer_prog = "uncompress";) >>> >>> >>> even though OPT_COMPRESS is a constant zero. >> >> The same prob exists with clang, apparently, Here's a bugreport >> filed against debian package of busybox: http://bugs.debian.org/789499 . >> The proposed fix is to apply the above patch only if building >> with clang :) >> >> Basically, I'm not sure relying on dead code elimination like this is >> a good idea. I mean, the code is eliminated, there's no if() statement >> in the generated code, so it is okay, but it looks like clang still >> records symbols referenced in the eliminated code. Sometimes it >> is actually a good idea to keep ref symbols, eg when you build an >> executable which can load modules, so that modules will use symbols >> in that executable. >> >> Thanks, >> >> /mjt >> _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
