Mail Archives: cygwin/2003/02/08/20:28:47
> From 'info libtool':
>
> `pass_all'
> will pass everything without any checking. This may work on
> platforms in which code is position-independent by default and
> inter-library dependencies are properly supported by the dynamic
> linker, for example, on DEC OSF/1 3 and 4.
>
> From ltmain.sh:
>
> echo "*** Warning: Linking the shared library $output against the"
> echo "*** static library $deplib is not portable!"
>
> and
>
> if test "$alldeplibs" = yes &&
> { test "$deplibs_check_method" = pass_all ||
> { test "$build_libtool_libs" = yes &&
> test -n "$library_names"; }; }; then
> # We only need to search for static libraries
> continue
> fi
>
> which seems to imply that when building a shlib, we won't add the
> dependencies -lfoo -lbar to the link command, if libfoo and libbar are
> shared libs. But on cygwin/windows, all dependencies must be satisfied
> at link time...unlike ELF.
>
> In our case "position independent" is technically true for all object
> files -- -fpic does nothing. However, it is STILL possible that one
> would compile code one way for inclusion within a shared library (e.g.
> -DBUILDING_DLL) and differently when making a static library. There are
> still extant cases in current cygwin libraries where the DLL and the .a
> are *not* interchangable, since the client code must be compiled with
> -DBUILDING_STATIC or some such. A relic of the "old way" when we had to
> define __declspec(xxxxxx). So static libs and shared libs are not
> necessarily drop-in replacements for each other.
>
Thanks for this pointer. It seems to me, that you are much more deeper in the
libtool stuff as I am.
> So, interlibrary dependencies are not automatic.
>
> > cygwin* | mingw* ) lt_cv_deplibs_check_method='pass_all' # RH
> > cygwin* | mingw* ) lt_cv_deplibs_check_method='file_magic' # CW
>
> Which is not to say that it won't work to do it your way -- IF and only
> IF you are (a) linking only to new-style, non-declspec()-using
> libraries, or (b) are linking only to libraries built (new-style) as
> part of your package. E.g. KDE.
>
> In the future, it might be possible to use 'pass_all' on cygwin
> (assuming the point about 'dropping -lfoo -lbar' mentioned above doesn't
> apply) -- but I doubt that we'll ever get rid of some of the special cases.
>
For the answer see my next mail, which describes a way solving this all without
pass_all. :-)
> Worse, using pass_all means that a lot of different (read: untested on
> cygwin) codepaths are used, for all of the esoteric features of libtool
> like staticlinked -dlopen'ed modules, or dynamically linked modules that
> depend on other sharedlibs that are part of the same package, etc etc.
> As complex as KDE is, I doubt it really exercises ALL of the possibile
> permutations and uses of libtool.
>
> I presume that you have run the entire libtool test suite with your
> proposed change, and it passed all tests except for build_relink2 and
> quote? If not, then, well...I don't have time to do your homework, and
> the current mechanism has had a three month shakedown period. I expect
> libtool-1.5 within *days*.
>
> > Also in case you tell me that this is to late, see this for
> information purpose.
>
> Understood, but...
>
> > I can see from this, that major unix platforms use 'pass_all', so
> there couldn't
> > be so much issues.
>
> Ha ha ha ha ha ha hee hee hee hee. Oh, it is to laugh.
>
> Ralf, cygwin is not unix. cygwin is not linux. cygwin is not solaris.
> cygwin is not irix. cygwin is cygwin. Our runtime loader is crap.
> We don't have ld.so.conf. We don't have ld.so. We don't use ELF format
> for our shared libraries or object code. We have Microsoft's
> bastardized implementation of a runtime loader, that has led to an
> industry curse-word: DLL HELL. We have PE/COFF format object code.
>
> cygwin is different. Just because it works one way on linux -- and
> *may* work the same way, in a narrow range of usages expected by KDE, on
> cygwin, doesn't mean that cygwin and linux/solaris/irix/etc are
> interchangable.
>
> I note that once again, rather than trying to help me speed up the
> function you complained about, by testing my various proposals, you are
> instead chasing down rabbit trails and wandering in the weeds -- and not
> presenting evidence that you HAVE, in fact, actually tested your own
> ideas, much less mine. (actually, I do assume that you have tested your
> ideas, but you haven't *told* me that you have done so.)
>
I can only say it again. See the next mail.
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -