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

[Charles Wilson]

 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.

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.

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.)

--Chuck


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