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__
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
