Wouldn't replacing -DPIC with -D__PIC__ break a fundamental
assumption about ANSI compilers, that "__" means compiler-defined
and not in the userspace?
IMHO, I have yet to see an example of how it could be useful
to define "PIC" when it seems that the only way to make use of
it is to have it surround severely implementation-specific stuff
like inline assembler in which case the compiler _should_ be defining
"__PIC__" or some similar symbol. The big problem with -DPIC is
that it is very easy to clash with some other macro. It has only
three letters and so is very likely to clash with other macros.
Don't believe it? A quick google search for "#define PIC" returned
this as the second result:
www.ddj.com/ftp/2001/2001_01/int_late.txt
... stdio.h> #include <dos.h> /* interrupt related definitions */
#define CLK_TICK_INT
0x08 /* The clock tick interrupt */ #define PIC 0x20 /* Programmable
...
5k - Cached - Similar pages
The 5th result showed another example of using "PIC" that would clash,
and the 11th contains this snippet in reference to inline sparc
assembler:
#if (defined(__pic__) || defined(__PIC__)) && !defined(PIC)
#define PIC 1
#endif
The main problem with removing -DPIC is that there is a backward
compatability issue. This issue would STILL exist if we renamed
PIC to a sensible name like LT__PIC__, and since compilers provide
this it doesn't seem necessary to keep it at all.
That's why my plan is to deprecate it for 1.5, and remove it in
a future release.
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: rboehne AT ricardo-us DOT com
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
