Re: libtool devel package still dll crippled.
Danny Smith wrote: > > > Todo: > > > > 2b) set an option like "--export-libs=*" or something else > > > > 2c) identify the libs to export and set an option like > > "--export-libs=lib1,lib2," > > > > Do I need to refresh the patch I submitted to binutils many moons ago. It > is useful its own right (building dlls without libtool magic). > IIRC "--export-libs=*" won't work becasue of globbing problems. It needs > to be something else like "--export-libs=ALL" > Yes, I think so. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: libtool devel package still dll crippled.
> > 2b) set an option like "--export-libs=*" or something else > > 2c) identify the libs to export and set an option like > "--export-libs=lib1,lib2," > Ups, I have overseen some errors in the logic above. Additional Danny has used "--exlude-libs", so the logic must be negated 2b) set an option like "--exclude-libs=*" or something else 2c) identify the libs not to export and set an option like "--exclude-libs=lib1,lib2," Sorry, Ralf
RE: libtool devel package still dll crippled.
> Todo: > > 2b) set an option like "--export-libs=*" or something else > > 2c) identify the libs to export and set an option like > "--export-libs=lib1,lib2," > Do I need to refresh the patch I submitted to binutils many moons ago. It is useful its own right (building dlls without libtool magic). IIRC "--export-libs=*" won't work becasue of globbing problems. It needs to be something else like "--export-libs=ALL" Danny http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE!
RE: libtool devel package still dll crippled.
> Is there any real solution to this problem w.r.t. > the current -devel version of libtool? > I guess no. Perhaps the following helps for this topic. When building libs, there are some cases, which could be choosed. Have I forgotten any ? Building does export symbols used from type static libs dll's 1a. static lib yes no 1b. static lib nono 1) 2a. dll'syes no 2b. dll'snono 2c. dll'syes/nono 1) Is using a static lib only for resolving internal references real ? Current libtool devel state: Case 1a, 2a Wished states to add: 2b, 2c and perhaps 1b Todo: 2b) set an option like "--export-libs=*" or something else 2c) identify the libs to export and set an option like "--export-libs=lib1,lib2," Libtool has the possibilities to distinguish A) added libs from B) depending libs for example A) libkdeui_la_LIBADD B) libkdeui_la_DEPENDENCIES which could be used. Unfortunally for kde I have seen that only A) is used in any case. So at this point, my question is how libtool handle this task on other os like linux. There must the similar problems. Any comments ? Ralf
Re: libtool devel package still dll crippled.
Is there any real solution to this problem w.r.t. the current -devel version of libtool? Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: libtool devel package still dll crippled.
> I'm using a special patched ld (based on the
> recent official
> > ld) which rejects exporting of all imported
> libs with a one
> > line patch
> >
> > binutils/ld/pe-dll.c:234
> > /* Do not specify library suffix explicitly, to
> allow for
> > dllized versions. *
> > static autofilter_entry_type autofilter_liblist[] =
> > {
> > { "libgcc.", 7 },
> > { "libstdc++.", 10 },
> > { "libmingw32.", 11 },
> > +// RH: workaround to allow using static libs
> in multiple
> > dlls
> > + { ".a", 2 },
> > { NULL, 0 }
> > };
>
>
> I really think this is a mistake. What if I want
> to build a shared
> library using libtool, and it is composed of a
> number of object files
> but also some convenience libs? And those
> convenience libs contains
> symbols that I want to export?
I have not said, that this workaround is a general patch
usable
in all situations. Because KDE does create only dll's this
was okay for me.
Dannys patch is of course the beest solution, but it
requires
some (as I recognized after reviews this patch) deeply
changes of the
libtool implementation, which isn't not easy. :-(
Ralf
Re: libtool devel package still dll crippled.
Ralf Habacker wrote:
>>must be some way to prevent ld outputting the imported
>>
> symbols as
>
>>well as the exported symbols...
>>
>
> I'm using a special patched ld (based on the recent official
> ld) which rejects exporting of all imported libs with a one
> line patch
>
> binutils/ld/pe-dll.c:234
> /* Do not specify library suffix explicitly, to allow for
> dllized versions. *
> static autofilter_entry_type autofilter_liblist[] =
> {
> { "libgcc.", 7 },
> { "libstdc++.", 10 },
> { "libmingw32.", 11 },
> +// RH: workaround to allow using static libs in multiple
> dlls
> + { ".a", 2 },
> { NULL, 0 }
> };
I really think this is a mistake. What if I want to build a shared
library using libtool, and it is composed of a number of object files
but also some convenience libs? And those convenience libs contains
symbols that I want to export?
Blindly refusing to export the symbols from anything that ends in .a is
a mistake, IMO. (I could be convinced that re-exporting symbols
obtained from a .dll.a is always bad, and should be screened out using
the brute-force, non-overrideable method in the patch above, but not .a)
--Chuck
RE: libtool devel package still dll crippled.
> > _LT_AC_TAGVAR(always_export_symbols, $1)=yes
> >
> > Using "yes" causes libtool to use nm to
> generate a symbol
> > list, which is avoided by setting to "no".
>
> Are the symbol tables identical in both cases?
If have done a short try (nm of the two import libs and
diff) with a little helper project and they are the same
> Would Danny's whole archive patch help the symbols?
May be, I haven't tried yet. Do I remember right, that this
patch isn't in the official binutils releases yet ?
> must be some way to prevent ld outputting the imported
symbols as
> well as the exported symbols...
I'm using a special patched ld (based on the recent official
ld) which rejects exporting of all imported libs with a one
line patch
binutils/ld/pe-dll.c:234
/* Do not specify library suffix explicitly, to allow for
dllized versions. *
static autofilter_entry_type autofilter_liblist[] =
{
{ "libgcc.", 7 },
{ "libstdc++.", 10 },
{ "libmingw32.", 11 },
+// RH: workaround to allow using static libs in multiple
dlls
+ { ".a", 2 },
{ NULL, 0 }
};
Ralf
RE: libtool devel package still dll crippled.
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 6:15 PM > I had recgonized problems with the > allow_undefined_flag=unsupported and have tried only with > "no", which works. Yet I have tried with "yes" it works too. > So its no problem for me to use "yes". Cool. Using yes (or blank, blank is preferred IIRC), means that a purely unix package will build .dll's on cygwin, without any hacks needed (given the auto-import caveats_. > _LT_AC_TAGVAR(always_export_symbols, $1)=yes > > Using "yes" causes libtool to use nm to generate a symbol > list, which is avoided by setting to "no". Are the symbol tables identical in both cases? Would Danny's whole archive patch help the symbols? I think there must be some way to prevent ld outputting the imported symbols as well as the exported symbols... Anyway, setting always_export to 'no' should be ok for now. Over the next week I'll do some testing and get back to the list. Rob
RE: libtool devel package still dll crippled.
> > From: Robert Collins > > Sent: Sunday, April 14, 2002 9:43 AM > > > > 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? > > > > We want "...=". In both locations. > > > > I'll test the always_export_symbols settings > now and send > > another email when that build is done. > > I think we should leave the always_export_symbols > as yes, but I'm not > religious. > > Ralf, whats the reason to change that to no? > > I get better results with it set to yes, which is > why I am asking.. > I had recgonized problems with the allow_undefined_flag=unsupported and have tried only with "no", which works. Yet I have tried with "yes" it works too. So its no problem for me to use "yes". _LT_AC_TAGVAR(always_export_symbols, $1)=yes Using "yes" causes libtool to use nm to generate a symbol list, which is avoided by setting to "no". /usr/local/bin/nm -B .libs/profiler.o | sed -n -e *[ ]\([ABCDGISTW][ABCDGISTW]*\)[ ][ ]*\(_\)\([_A- Za-z][_A-Za-z0-9]*\)$/\ 1 \2\3 \3/p' | sed 's/.* //' | sort | uniq > .libs/libprofiler.exp In small projects this may be no difference, but if you have to build hundrets of dll's with thousands of symbols this makes a difference in linking time. Does the cygwin ld really need this way of creating symbol lists ? Ralf
RE: libtool devel package still dll crippled.
> -Original Message- > From: Robert Collins > Sent: Sunday, April 14, 2002 9:43 AM > > 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? > > We want "...=". In both locations. > > I'll test the always_export_symbols settings now and send > another email when that build is done. I think we should leave the always_export_symbols as yes, but I'm not religious. Ralf, whats the reason to change that to no? I get better results with it set to yes, which is why I am asking.. Rob
RE: libtool devel package still dll crippled.
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 9:31 AM > To: Robert Collins > Cc: Cygwin-Apps > Subject: Re: libtool devel package still dll crippled. > > > 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? Sorry, I was unclear. Ralfs alteration is at the right place, but IMO wrong. It should leave always export = yes, and set "allow_undefined=". This works for me with .dll's and C++. I'll try Ralf settings now and see how it goes. > 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? allow_undefined_flag should be "..=". IMO that is. I'm trying to get rid of the configure.in AC_LIBTOOL_DLL garbage, and make it transparent to the user. There is a lot to do - yes. > 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. Which is why setting it to "..==" is correct. > 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? We want "...=". In both locations. I'll test the always_export_symbols settings now and send another email when that build is done. Rob
Re: libtool devel package still dll crippled.
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
RE: libtool devel package still dll crippled.
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 8:23 AM > However, Ralf has the *opposite* problem: What Ralfs patch does is change allow_undefined_flag to no (as opposed to unsupported) and 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). Rob
Re: libtool devel package still dll crippled.
Robert Collins wrote: > Line 4476 of libtool.m4 setups allow_undefined to 'unsupported' for > Cygwin. With --auto-import this is incorrect. It should set it to "...=' > > I *think* that's all I had to do to get the auto-import magic back on > track :}. > > Chuck, > I hate to be a bother, but is this enough for you? And do you have time > to drop a patch back to the libtool list? (I don't have the CVS source > checked out currently, so it is more efficient for you to do this... Well, I'm somewhat confused. I had already changed one "allow_undefined" for cygwin from '...=unsupported' to '...=' (line 2566). Didn't realize there was another one that applied. However, Ralf has the *opposite* problem: http://cygwin.com/ml/cygwin/2002-04/msg00362.html So I don't know WHAT to do. Ralf, does Robert's fix corrent your problem? Rob, does Ralf's fix correct your problem? --Chuck
