On Tue, 29 Nov 2005, Ralf Wildenhues wrote:
This seems to me the superior solution. Thus, let's kill the
--with-pic idea, too. It won't get us over main.o
compiled-without-libtool and neither one of -fpic or -fpie in
CFLAGS anyway. And I can't see why it should be more useful to
have two PIC objects rather than one PIC and one PIE object.
I don't know, but PIE and PIC don't compile to same thing AFAICT. I
don't know the significance of that though.
AFAIK there isn't. gcc defines __PIC__, __pic__. Thus one open
question would be whether we should notify the compiler/assembler
that PIE code is created. We could `-DPIC -DPIE', for example (PIC
because most assembler code will likely work unmodified from the
PIC version,
Depends on the constraints I guess. Most sane asm will be inline and
operating on indirect memory references in parameters setup by GCC,
those would be relocatable. But anything is possible with asm ;).
see http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00145.html ). Or,
to not avoid further namespace invasion, maybe `-DPIC -DLT_PIE'.
For CC and CXX tags? Suggestions? Maybe only add -DPIC?
One weak reason against adding anything would be the fact that
non-libtool created PIE objects would not see the define either. :-/
(Actually, that could be interpreted as reason for the program author
to rely on __PIC__ or __pic__ iff this is gcc-specific code anyway.)
Why not leave the define to GCC? You pointed out gcc sets defines for
PIC. That would work for the non-libtool-compiled object case too.
Ie any problems arise here will be due to missing functionality in
GCC, and likely remedied there in due course as PIE becomes more
commonly used.
Well. It's implemented in GNU binutils ld as of recently enough,
GCC as of recently enough, and with them is said to work on all ELF
systems.
Interesting to know. I just tried with GCC 3.4.3 as supplied with
SNV_09 and, while it accepted -fpie -pie on the commandline, the
resulting executable was not reported as relocatable by 'file'.
Any other ones? Does the Solaris linker support it, for example?
Not at the moment no.
My tests with gcc-3.4.4 show that -fpie/-fPIE always override
-fpic/-fPIC, independent of the order in which they were passed.
(What an unfortunate choice, by the way. Oh well.)
Indeed. I think that has been discussed on the gcc lists.
Libtool then does this (implemented in patch below):
- strip -pie/-fpie/-fPIE from compile flags for PIC objects
and from LTCFLAGS for compilation of the symfile object as that one
should be PIC (I believe stripping from LTCC is not needed: putting
`-pie' in CC will break creating shared libraries; don't do that).
- strip -pie/-fpie/-fPIE from link flags for libraries, but
not for programs: actually, this needs no changes; libtool already
does exactly the right thing here.
Yep that could work.
I'd be glad if someone could test CVS HEAD with the patch below on a
bunch of packages, and/or with the Libtool test suite.
I'll give a try soon.
On GNU/Linux, x86_64, the test suite fares pretty good:
Nice :)
Cheers,
Ralf
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
Fortune:
Common sense is the collection of prejudices acquired by age eighteen.
-- Albert Einstein
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
