This is the mail archive of the cygwin@cygwin.com 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 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/


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