Subject: Re: Ping: Cygwin libtool / assembler problem with -DPIC
From: Charles Wilson <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 14 Oct 2004 20:17:49 -0400

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/