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
