Gerrit P. Haase wrote:
I think it is a bad thing to add -D flags unconditionally and for sure it is a bad thing if it is a noop.
You're missing the point. *libtool* doesn't know that -DPIC means nothing for your code. On some platforms, you really have to compile DIFFERENT CODE, not just compile the same code in a different way (-fpic), when you want to make a pic object.
So Libtool is merely supplying a compile define as a hint, that you can then use in your code:
#if PIC this stuff is pic-safe #else do it some other way #endif
It's no different than in the bad old days, when libtool gave us DLL_EXPORT:
#if DLL_EXPORT #define decoration declspec(__dllexport__) #else #define decoration declspec(__dllimport__) #endif
It was up to the client code to cooperate with the -DDLL_EXPORT symbol; to use it in the right way; to not use it in ways that didn't work with libtool, etc.
Same with -DPIC. gmp attempts to do that, but is going about it wrong IMO.
The answer should be to not define -D flags which do nothing, let the user decide which -D flags she wants, these are CFLAGS after all.
See above. Libtool is providing a symbol that COULD, even on cygwin, be of some use. You cannot specify it as an AM_CFLAGS because it should be "on" when building .lo's and "off" when building .o's -- and AM_CFLAGS don't allow that fine-grain control. So libtool does it.
Should do it, yes, however, why not undefine it in libtool, I still don't see the reason why it is used at all.
It is not used by gmp. It might be used by ncurses. Or Orbit. Or any one of the thousands of other libtoolized packages. You're asking me to unilaterally remove a feature from libtool that other packages may already be using, because gmp doesn't use it and gets confused by it?
That's a gmp bug, not a libtool bug.
And yes, GMP should not care that much about its own machinery, if there is a flag in libtool that prevents generating working code then obviously the used tool is broken and should be fixed, defining these workarounds because buildtools are broken is not the way to go.
The buildtool is not broken. It's providing a hint to the package(gmp in this case). It's not libtool's fault that gmp doesn't properly interpret that hint on cygwin; gmp DOES interpret the hint properly on other platforms ["properly" == compiles the correct code]. And gmp already has a workaround to adapt its own funkiness to work with libtool on cygwin. Gmp's workaround is
ifdef(`DLL_EXPORT',`undefine(`PIC')')
(translation: on most platforms, obey -DPIC. if PIC undef, compile non-pic asm instructions; if PIC def, compile the other instructions.
BUT, if DLL_EXPORT (e.g. if cygwin|mingw)) then gmp should always compile the non-pic asm instructions. This is a gmp-specific exception; other packages may, even on cygwin, unlike gmp, want to behave differently when -DPIC/-UPIC.
But, because DLL_EXPORT does not mean "platform == cygwin|mingw", we need to change this gmp-specific workaround to one that is actually correct:
if (eq(`PLATFORM',`cygwin'),`undefine(`PIC')')
(I'm sure my syntax is wrong, but you get the idea)
Because
Haible's packages nearly always include hacked versions of libtool or m4 macros it is always a pita to apply newer libtool versions, i.e. simply doing autoreconf fails in most of the cases (CLN, gettext, libiconv, GMP, ...choose your favourite Haible package...).
Yes, I know. That aspect of Bruno's code annoys me to no end.
Of course, you're defeating your own argument here. Why should I change the "official cygwin" libtool, or push changes upstream to the "real" libtool, to fix gmp -- when Bruno won't use the stock version anyway?
-- Chuck
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
