Rob Landley has an opposite view: preprocessor #if's are evil. I agree with him that they do tend to obfuscate.
On Sun, Jun 28, 2015 at 9:44 AM, Michael Tokarev <[email protected]> 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 [email protected] http://lists.busybox.net/mailman/listinfo/busybox
