Hello Gary,
Gary V. Vaughan <[EMAIL PROTECTED]> wrote:
GVV> [[Moved back to libtool list, but left all the context for people who
GVV> don't follow libtool-patches]]
GVV> Hi Paul,
GVV> Sorry this isn't a full reply -- I'll try to get back to you when I
GVV> have had time to look over your patch.
Thanks, though it seems that main point - portability problems,
expressed here.
>> > I still hope to implement way which will allow building dlls without
>> > any changes to sources/build files.
>>
>> Good luck :-)
GVV> Been there! I am open to suggestions having hit a few brick walls
GVV> myself!
I postponed that original work for later time since so far little
changes to libtool I posted even before. For example, I built couple
of gnome libs without any (dll-related) changes. But just one more
deeper step resurrects mutual dependency problem. For example, glib
cannot be built properly, since there's cycle between it and gthread.
GVV> I need to trawl through my mail archive to jog my memory, but I do
GVV> recall being moderately convinced at the time =)O|
Then I hope you'll consider my previous patch (libtool-patch from
2000-07-27).
>> > It is asked to install (shared) library and should do it. If there's
>> > platform on which shared libraries smeared across two files, one
>> > called 'implib' and one called 'dll', both preferrably installed in
>> > different dirs, it should do it, silently
>>
>> Not if it can't tell what is the preferrable directory. And, in
>> general, it can't. I'd rather not do a partial job.
GVV> But with libtool, the dll is *not* smeared across two files.
And that's bad. They have to, if we going to solve mutual dep
problem.
GVV> I wrote
GVV> the impgen program so that a static implib is generated on the fly,
GVV> allowing libtool to treat the dll part as the whole library for the
GVV> rest of the time.
*This* is oversimplification. Last anecdote is that cygwin people
were so brave to make (some late snapshot of) ld do that
automagically. Moreover, they did linking agianst DLL the default
(i.e. when asked to link -lfoo and there's (lib)foo.dll and libfoo.a files available
in search path (dunno which one), former is selected, in-memory implib
created, and app linked against it). However, they fall back (to
.a - default) when it became obvious that it gives too much confusion
and unexpected results.
GVV> The tradeoff is that we have to jump through some
GVV> hoops (building and running the impgen program for on the build host)
GVV> in order to perform a simple link. The key is in realising that
GVV> Windows uses the binary search PATH to find dlls (I know that is an
GVV> oversimplification!).
[]
GVV> Not to mention that ltconfig will go away soon. The only interfaces
GVV> to libtool will be via configure.in (and ultimately configure) and the
GVV> libtool script itself (presumably as called by the Makefile).
All I can say is that it gives me a shiver ;-)
GVV> I think that Windows forces us to admit that $shlibpath_var is PATH,
GVV> and that a Windows user of libtool generated dlls must have the
GVV> library installation directories in their PATH. Maybe we should
GVV> install a wrapper script that takes care of this?
But isn't it done that way? Wrapper script to run not yet
installed binaries sets PATH to required .libs directories.
Original talk was however about question where to *install* DLLs.
Obvious solution is to the same place where .a files, but that will
require additional entry to PATH. Being efficiency liker (hm), I prefer
other approach - employ more or less smart heuristics to find $bindir
within libtool's runtime scope.
>> Thanks for trying to fix this mess. I really hope some day we won't
>> have to make contortions to be able to support shared libraries on
>> MS-Windows. I wish you luck with the PW effort, even if your aim is
>> not to fully replace the way DLLs are built with something that is
>> more developer-friendly.
GVV> Most definitely!
GVV> Cheers,
GVV> Gary.
--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
