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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
