Mail Archives: cygwin/2004/10/14/20:18:18
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
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -