Mail Archives: cygwin-apps/2002/04/13/19:28:52
Robert Collins wrote:
> What Ralfs patch does is change
> allow_undefined_flag to no (as opposed to unsupported) and
?? what's the difference between "...=unsupported" and "...=no" and
"...="? Shouldn't the SAME answer be given in all sections, with
respect to whether "allow_undefined_flag" is a legal option?
Granted, you can't build a DLL -- in any language -- if there are
undefined symbols. But if I want to use libtool to build a static lib,
I should be allowed to have undefined symbols. Fine -- by default
cygwin-libtool asserts -no-undefined, so I need to override that. SO,
allow_undefined_flag needs to be "yes" or "supported" or "...=", right?
I don't understand how merely allowing a user to supply a flag hurts
Ralf's KDE build -- unless he is (mistakenly) USING that flag (even
though he shouldn't when building a DLL).
And I REALLY don't want to disallow people from building static libs
with undefined symbols using cygwin libtool.
> always_export_symbols to no (as opposed to yes).
>
> Now I'm not entirely sure what always_export_symbols does...
>
> Anyway, the reason there are multiple locations is that libtools guts
> are horrendous. There are folk putting time into factoring libtool to be
> a little bit more consistent and efficient though...
>
> The location I refer to us in AC_LIBTOOL_PROG_LD_SHLIBS, where as Ralf
> altered AC_LIBTOOL_LANG_CXX_CONFIG (which needed the alteration too - it
> effectively includes a copy of AC_LIBTOOL_PROG_LD_SHLIBS).
Okay, my patch conflicts with his. Original CVS (20020316) (ignoring
the always_export_symbols thing):
_LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
My patch:
_LT_AC_TAGVAR(allow_undefined_flag, $1)=
Ralf's patch
_LT_AC_TAGVAR(allow_undefined_flag, $1)=no
Again, the "...=" came from you, Rob. So, what's the difference between
"...=" and "...=no" or "...=unsupported" (or "...=yes", for that
matter). And which do we want/need?
--Chuck
- Raw text -