[gentoo-dev] problems, gcc woes, CFLAGS and et_dyn

[Joshua Brindle<method@gentoo.org>]

Alexander Gabert has been working very hard on getting et_dyn (ALSR)

here is my report, with problem classification already:

1) propolice: problems with __guard symbol not referred correctly
-----------------------------------------------------------------
grub (the boot loader) misses __guard in some of it's parts when compiling and fails
cracklib misses __guard which is not in the @GOT in the library referred(?)
hsi from Adamantix already suggested a workaround for that...
investigating... Hiroaki has to say something about that...

2) etdyn: Makefiles that forget to define -lcrypt or other -l*
--------------------------------------------------------------
sys-libs/pam gets through when the Makefile is changed to include
-lcrypt in the _right_ place where gcc is invoked
funny though that this only uncovers with etdyn :-)

3) etdyn: old style system calls via assembler constructed interface
--------------------------------------------------------------------
lilo uses the old llseek syscall (like fdisk used in util-linux)
net-ftp/proftpd uses a system call to check for capabilities(?)

4) etdyn: failing configure scripts due to broken libraries
-----------------------------------------------------------
net-misc/ntp breaks because -lreadline is unable to resolve some symbols
when doing a conftest in configure ... here is the fast workaround:
the mistake only appears with a dumb ./configure conftest.c
set CC='gcc -static' for the configure part and then let the following
script rush through the dir:
find . -name "Makefile" -exec sed -i -s 's:gcc -static:gcc:' {} \;
then, do make and get etdyn executables though the configure is broken.
disadvantage: is linux and gcc centric, need to find a better way,
i have to report to the appropriate upstream!


So the conclusion is that using CFLAGS and LDFLAGS to build an et_dyn system
is not adequate and something else must be done. The current solution
is to use gcc-config to switch the default spec file but this has a number 
of downfalls, we'd like any other thoughts, opinions, or ideas .. Thanks


Joshua Brindle

--
gentoo-dev@gentoo.org mailing list