Ralf Wildenhues ([EMAIL PROTECTED]) wrote:
(It'd be great if you could enable your mailer to wrap long text lines.)
* Kevin F. Quinn wrote on Thu, Jan 27, 2005 at 09:18:57AM CET:
Thanks people; I understand (now) that libtool supports many targets,
each with their own compilers. I guess that means the question
becomes, why set -DPIC on targets that use gcc, where that compiler
defines __PIC__ if it's generating PIC code (at least since gcc 2.8.1
to my knowledge - I don't know about earlier versions)?
Well, -DPIC means just that: you are compiling for position-independent
objects.
To be specific here, it means libtool has set the options for PIC. If the
options for PIC are set by other means (i.e. not when using libtool, but
perhaps by changing the compiler configuration), -DPIC may not be. I know this
sounds pedantic, but I'll elaborate an example below to clarify where I'm
coming from. BTW I'm not suggesting libtool change its behaviour (if nothing
else no doubt lots of stuff would break as a result, regardless whether it's
redundant on a platform or not), but I do want to make sure I understand
properly why libtool sets -DPIC, and so when and why one should write '#ifdef
PIC' rather than '#ifdef __PIC__'
Presumably stuff that needs to use conditional compilation for
PIC/non-PIC code is compiler- and target-specific, so should use
This is an assumption. Might be valid often, but is an assumption.
I figure it may valid, since PIC specifics depend on the ABI, which depends on
platform and toolchain. I'd be genuinely interested in an example where it's
not valid, though.
whatever support is provided in each case (where libtool could add a
define if otherwise there's nothing available from which to decide on
a given platform). In the case of gcc targets, I think '#ifdef
__PIC__' should always be used, however there's a lot of code out
there doing '#ifdef PIC' inside GCC-specific assembler blocks (for
example).
How are you going to use gcc-specific assembler in portable software?
By surrounding it with '#ifdef __GNUC__' etc and providing alternative source
code for other platforms. A common occurrence in multimedia software where
performance is paramount for many users, is provision of hand-written assembler
for the x86 platform (often several variants, using various combinations of
SSE, MMX etc) with alternative normal non-assembler code for others (PPC, MIPS
etc). The code is then switched automatically with suitable preprocessor
directives. That way you can support any platform, while at the same time you
don't have to sacrifice performance on platforms that need specific
instructions to get it.
Why specifically do you mind `#ifdef PIC' in the gcc-specific assembler?
I mean, it's not going to be compiled by any other compiler anyway
(and if so, one could arguably expect the other compiler to need the
very same PIC-special code anyway).
I'd like to be able to say to people who use '#ifdef PIC'
for gcc-specific code (e.g. stuff inside an '#ifdef __GNUC__' block)
that they should be using __PIC__, and get it fixed accordingly.
Why? I mean, you can say that, but what does it buy you?
These questions are honest. Maybe it's best to provide a specific
example why you think existing practice is not best.
Here's the example where '#ifdef PIC' causes problems. In the Gentoo Hardened
project, in order to build a system whereby as far as possible all software is
PIC/PIE to take advantage of address space randomisation, the default gcc
compiler configuration is altered to generate PIC on the x86 platform. Where
software is written conditionally on '__PIC__', it can work ok, unchanged (it
might be slow, but that's a secondary consideration in this case). Where code
is conditional on 'PIC', it breaks (if the build isn't using libtool). The
decision I'm trying to make is whether to suggest to people they should write
'#if defined(PIC) || defined(__PIC__) instead of '#ifdef PIC', or whether to
suggest '#ifdef __PIC__'. It seems that unless the build uses libtool (in
which case it probably works anyway), I can safely suggest the latter for
gcc-specific code.
I would guess that perhaps people have lifted code from other packages which
are built with libtool or similar (and hence use '#ifdef PIC'), without
understanding properly where the definition comes from, and have then pasted
that code into their own projects that aren't built with libtool. Another
possibility is that developers see '#ifdef PIC' in many bits of code, and
assume that's always the way to decide PIC or not.
Thanks,
Kev.
___
http://lists.gnu.org/mailman/listinfo/libtool
