Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC

[Guido Draheim]

Simon Richter schrieb:
> Robert,
>
>
> > Ok, here it is.  This patch changes AC_LIBTOOL_PROG_COMPILER_PIC
> > so that it only appends -DPIC to the default "C" tag and the CXX
> > tag for C++.  I would also like to deprecate -DPIC in the 1.5 release
> > to make it clear we intend to do away with it.  I would also like
> > to ask anyone who does depend on this to let us know when/where/why &
> > how
> > so we can add a section to the documentation on how to modify
> > code to not need -DPIC.
>
>
> Inline assembler is compiler dependent anyway. So for inline assembler
> the correct syntax is
>
> #if defined(__GNUC__) && !defined(__PIC__) && defined(__i386)
>         asm( /* Non-PIC asm implementation */ )
> #else
>         /* C implementation */
> #endif
>
> or, respectively
>
> #if defined(__GNUC__) && defined(__i386)
>         asm( /* PIC asm implementation */ )
> #else
>         /* C implementation */
> #endif
>
> Perhaps there should also be a small comment why #ifndef __PIC__ is not
> enough.
>
> If you have compiler independent code that you want to conditionally
> compile depending on the PIC setting, you have a real problem now, since
> there is no longer a standardized preprocessor symbol, and you cannot
> work around that. It may be worth investigating whether glibc has such
> portions (they don't use libtool, but set -DPIC for themselves when
> compiling the shared library; there are lots of #ifdef PIC in the code)
> and whether this warrants a check in configure whether we need to set
> -D__PIC__ in order to get that feature back.

Yes, it should be portable still.

btw, once up a time I had severe problems with porting an application
trying to make it into a library - the software did use PIC as one
of its symbols, a #define PIC struct picture. That's actually quite
naturally for the original programmer - PIC is short, it is written
in big caps for being a define, and it does not use a "__" prefix
that is used for "reserved" symbols.

But we need to care about a PIC define somewhere, as I do have some
code too that depends on recognizing a sharedlib mode (library,
plugin, whatever). That's only minorily different from the original
meaning of PIC as that some platforms do not need / care for
position-independent code for its --enabled-shared plugins.

Currently, I wonder if it would be okay to just replace the current
definition of -DPIC with -D__PIC__. Well, ye know, people don't
actually read change infos when upgrading. With a -D__PIC__ showing
up on the commmand line, that might make things easier - and some
software with lots of PIC-use around can still make up a compatiblity
define in some header...

#if defined __PIC__ && !defined PIC
#define PIC
#endif

proposal: don't just delete -DPIC for C/CXX, replace it with -D__PIC__