I am having some issues with compiling stuff with dietlibc, namely missing main in stackgap. Example of this: /home/staff/doli/www/q/httpd-2.0.59/srclib/apr/.libs/libapr-0.a(shm.o): In function `apr_shm_attach': shm.c:(.text+0x584): undefined reference to `ftok' /usr/diet/lib-i386/libc.a(stackgap.o): In function `stackgap': (.text+0x6d): undefined reference to `main' collect2: ld returned 1 exit status make[1]: *** [httpd] Error 1 make[1]: Leaving directory `/home/staff/doli/www/q/httpd-2.0.59' Dietlibc folks say in the FAQ: " Q: I get an error message at link time, that "main" can not be found. A: Disable WANT_STACKGAP in dietfeautres.h or try upgrading your binutils. " would it be possible to actually fix the darn thing please? :)
What are you trying to compile? Also, post emerge --info output.
i'm trying to get apache working with dietlibc. it seems i got to the final linking process. configure options: export CC='diet gcc' export CFLAGS='-O -s -pipe' ./configure --prefix=/apache --disable-actions --disable-asis --disable-env \ --disable-include --disable-negotiation --disable-shared --enable-static --disable-so \ --with-expat=builtin emerge info: Portage 2.1.1 (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-hardened-r1 i686) ================================================================= System uname: 2.6.17-hardened-r1 i686 Pentium II (Deschutes) Gentoo Base System version 1.12.5 Last Sync: Fri, 15 Sep 2006 03:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r3 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-s -pipe -march=pentium2 -O3 -funroll-loops -fstack-protector" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-s -pipe -march=pentium2 -O3 -funroll-loops -fstack-protector" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distcc distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror http://gentoo.mirror.solnet.ch http://trumpetti.atm.tut.fi/gentoo/" LINGUAS="" MAKEOPTS="-j3" PKGDIR="/usr/portage//packages/x86/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/home/portagetmp" PORTDIR="/usr/portage/" SYNC="rsync://1g.compfort.com.pl/gentoo-portage" USE="berkdb bzip2 caps chroot clearpasswd crypt dlloader elf elibc_glibc ftp glibc-omitfp hardened input_devices_keyboard input_devices_mouse kernel_linux mbox minimal ncurses nptl nptlonly pam pam_chroot pam_timestamp pic pwdb readline sendfile sftplogging symlink tcpd threads userland_GNU userlocales x86 xinetd xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Need to reopen the bug.
to be honest, i'd prefer to completely disable all this pie/ssp/hardened crap in diet, it never worked, does not, and will probably never work... damn diet... any reason why you don't use uclibc?
any reason why one person uses firefox theme 'x' and the other 'y' ? :) no particular reason, it's just that dietlibc has worked for me for some time now and I consider it quite stable. Never played with uclibc though. doesnt it need at totally new toolchain?
(In reply to comment #5) > Never played with uclibc though. doesnt it need at totally new > toolchain? Sadly, yeah. But if you feel yourself capable to provide a patch for the STACKGAP thing (thing is, its broken UPSTREAM) feel free to do so ;)
hmm but who's right here? dietlibc people say its binutils' fault. you suggest that its dietlibc's. so whats the deal? :)
(In reply to comment #7) > hmm but who's right here? > dietlibc people say its binutils' fault. > you suggest that its dietlibc's. > > so whats the deal? :) Honestly, I've absolutly no clue whose fault it is. You could try it without the WANT_STACKGAP define (you'll either need to hack up a custom dietlibc or use a patch disabling it), and try it again. If it still isn't working its really binutils' fault. If it ain't working, its still dietlibc's fault.
(In reply to comment #8) > Honestly, I've absolutly no clue whose fault it is. You could try it without > the WANT_STACKGAP define (you'll either need to hack up a custom dietlibc or > use a patch disabling it), and try it again. If it still isn't working its > really binutils' fault. > > If it ain't working, its still dietlibc's fault. That doesn't make much sense, does it ? :P Working without WANT_STACKGAP -> dietlibc's fault Not working without WANT_STACKGAP -> binutils' fault
it seems that felix has recently added TLS (Thread Local Storage) support to dietlibc CVS, which is needed to use the stack protector with gcc 4.1.1, i.e. we can hopefully enable the SSP code again, instead of using the broken STACKGAP code once 0.31 is released we will start a new ssp testing round...
i added 0.31_pre20070503 to portage, which should support SSP natively with >=gcc-4.1, therefore obsoleting our stackgap/ssp patches please test
i have compiled dietlibc-0.31_pre20070612 successfully with gcc 3.4.6 (Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9) not sure whether it proves anything :)
