Re: -DPIC - redundant?

[Ralf Wildenhues]

Hi Kevin,

(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.

> 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.

> 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?
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.

Regards,
Ralf