Hi Charles,
> Libtool gives -DPIC -DDLL_EXPORT to indicate a cygwin or mingw DLL. We > undefine PIC since we don't need to be position independent in this > case and definitely don't want the ELF style _GLOBAL_OFFSET_TABLE_ etc. > ifdef(`DLL_EXPORT',`undefine(`PIC')') > Now, on *mingw*, we do indeed (up to now) define both DLL_EXPORT and PIC > which compiling .lo's. However, for cygwin, we no longer define > DLL_EXPORT, but continue to define PIC. So the little rule above is > ineffective, and gmp ends up compiling the wrong assembler code. Now I see, thanks. > Now, I'd call this a case -- maybe -- of gmp assuming too much about the > internals of libtool. OTOH, libtool emitting -Dcodes means that those > codes are supposed to be USED, right? > I'm not convinced that it is a BAD thing to emit a -Dcode indicating > when a source file is being compiled for a shared object, even when just > considering cygwin alone. I can see cases where one might want to > implement something differently within a shared lib vs. a static lib. > If we unilaterally remove -DPIC on cygwin, we can never do anything like > that. 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. > What gmp is doing is using the fact that "-DDLL_EXPORT" is defined to > indicate that the target platform is cygwin or mingw. It does this > because gmp "knows" that it DOESN'T want to use the special PIC-guarded > code on cygwin|mingw, *even* when building .lo's on those platforms. > (The fun part is gpm-h.in specifically says libtool's DLL_EXPORT is NOT > used. Errr...bzzt. Yes it is!) > However, DLL_EXPORT is an unreliable platform indicator, as we've > obviously seen here; it's only true when building .lo's on mingw now. > But I don't think just turning -DDLL_EXPORT back on for cygwin is the > answer, either. (I don't really remember when this stopped being on for > cygwin, but whatever). 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. > I think gmp's x86-defs.m4 needs to use $host (or whatever analogue it > can conjure up) to determine when the platform is cygwin or mingw, and > use THAT to decide when to undefine PIC. > Gerrit, if you change the line in x86-defs.m4 to ALWAYS undefine PIC, > does that fix your build problem even when libtool still -DPIC's? If > so, then certainly we can come up with a better way for gmp's config.m4 > machinery to determine its target platform, right? Should do it, yes, however, why not undefine it in libtool, I still don't see the reason why it is used at all. 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. 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...). I don't whine if all works as expected, but in case of GMP it is even impossible to build the vanilla source with the C++ lib included. Gerrit -- =^..^= http://nyckelpiga.de/donate.html _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
