Re: -DPIC - redundant?
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)? Presumably stuff that needs to use conditional compilation for PIC/non-PIC code is compiler- and target-specific, so should use 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). 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. Kevin ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -DPIC - redundant?
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
Re: -DPIC - redundant?
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
Re: -DPIC - redundant?
Kevin F. Quinn wrote: Apologies if this is a stupid question, but please could someone explain to me why libtool sets '-DPIC' for shared libraries, while gcc reliably defines '__PIC__' when it generates PIC code? Setting '-DPIC' encourages people to do '#ifdef PIC' when surely '#ifdef __PIC__' would be more reliable. Libtool supports plenty more compilers than just gcc. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -DPIC - redundant?
On Wed, 26 Jan 2005, Gary V. Vaughan wrote: Kevin F. Quinn wrote: Apologies if this is a stupid question, but please could someone explain to me why libtool sets '-DPIC' for shared libraries, while gcc reliably defines '__PIC__' when it generates PIC code? Setting '-DPIC' encourages people to do '#ifdef PIC' when surely '#ifdef __PIC__' would be more reliable. Libtool supports plenty more compilers than just gcc. I recall from discussions a couple of years ago that this define is even used from within some Fortran code. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -DPIC - redundant?
On Wed, 2005-01-26 at 08:21 -0600, Bob Friesenhahn wrote: On Wed, 26 Jan 2005, Gary V. Vaughan wrote: Kevin F. Quinn wrote: Apologies if this is a stupid question, but please could someone explain to me why libtool sets '-DPIC' for shared libraries, while gcc reliably defines '__PIC__' when it generates PIC code? Setting '-DPIC' encourages people to do '#ifdef PIC' when surely '#ifdef __PIC__' would be more reliable. Libtool supports plenty more compilers than just gcc. I recall from discussions a couple of years ago that this define is even used from within some Fortran code. IIRC, -DPIC predates -D__PIC__. So I'd guess older code had used #ifdef PIC, while __PIC__ has been to add to gcc. I don't know how other compilers handle this issue. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
-DPIC - redundant?
Apologies if this is a stupid question, but please could someone explain to me why libtool sets '-DPIC' for shared libraries, while gcc reliably defines '__PIC__' when it generates PIC code? Setting '-DPIC' encourages people to do '#ifdef PIC' when surely '#ifdef __PIC__' would be more reliable. ___ http://lists.gnu.org/mailman/listinfo/libtool
