[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Guido Draheim
Subject: Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Date: Thu, 16 Jan 2003 14:59:31 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826

Simon Richter schrieb:

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 &
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 */ )
        /* C implementation */

or, respectively

#if defined(__GNUC__) && defined(__i386)
        asm( /* PIC asm implementation */ )
        /* C implementation */

Perhaps there should also be a small comment why #ifndef __PIC__ is not

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]