This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [avail for test] libtool-devel-20030121-1

>  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
>     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  We don't have  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.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]