Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "cygwin" <cygwin AT cygwin DOT com>
Subject: RE: [avail for test] libtool-devel-20030121-1
Date: Sun, 9 Feb 2003 02:28:36 +0100
Message-ID: <006901c2cfda$9109bd70$0a1c440a@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3E4596B1.50103@ece.gatech.edu>

>  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/