Re: FYI: latest official cygwin libtool
Den 2009-02-26 05:39 skrev Charles Wilson: Peter Rosin wrote: *snip* Your resulting code is e.g. in some cases setting LT_AR to: LT_AR='$(SHELL) $(top_builddir)/libtool --quiet --mode=ar' but your libtool script does not support --mode=ar Yep. The patches/commits weren't quite as independent as I thought, and some that I pseudo-cherry-picked depended on others that I didn't. However, I'm not sure it is a wise thing to feed --mode=ar to the wilderness without an ok on the interface from at least one libtool maintainer? Meh. Cygwin doesn't use it, and it's broken so nobody will actually be ABLE to use it, so I might get some complaints on the cygwin list. But I doubt any of those complaints will show up on this list; and if they do, just blame me for pushing untested patches into the wild and tell the OP to check the real pr-msvc branch if they're really interested. You seem to think that the libtool you release in cygwin is limited to cygwin users. That is not the case. When some upstream package maintainer actually uses cygwin for development (I do), libtoolizes his/her package with your patches (I don't, but that's only because I happen to know there's a difference), releases a tarball, then every end-user of that package gets your patches. I think you have to consider that... Note that I made a mistake when I commited [2]. It was never intended to go into the pr-msvc-support branch without the above ok [4]. Oh. Didn't realize that. And the 07- patch seems to break ordinary crosses. Well now, that /would/ be bad. My version assumed that the toolchain is an ordinary cross toolchain which understands $build paths, except in cases where it knows it doesn't (i.e. $host=mingw, $build=mingw). Your version assumes that the toolchain is not ordinary, but instead one that understands $host paths (at least when $host is mingw or cygwin). That wasn't my intent. I was attempting to add the caching behavior (which, because of autoconf limitations, requires a whole separate case...esac tree from the to_host_path_cmd tree: you can't cache two different variables at once). But I hoped that, while using the different m4 code structure, the behavior stayed the same as yours. Hmmm, I now realize that I was confusing your patch with my unpublished rework of the patch that you found in the preview git tree. My reworked patch looks like this (I.e. it's no longer intertwined with the to_host check): +AC_MSG_CHECKING([how to convert $build paths to toolchain format]) +AC_CACHE_VAL(lt_cv_to_tool_path_cmd, +[#assume ordinary cross tools, or native build. +lt_to_tool_path_cmd=func_noop_path_convert +case $host in + *mingw* ) +case $build in + *mingw* ) # actually msys +lt_cv_to_tool_path_cmd=func_msys_to_mingw_path_convert +;; +esac +;; +esac +]) +to_tool_path_cmd=$lt_cv_to_tool_path_cmd +AC_MSG_RESULT([$lt_cv_to_tool_path_cmd]) +_LT_DECL([to_tool_path_cmd], [lt_cv_to_tool_path_cmd], + [0], [convert $build paths to toolchain format])dnl +AC_SUBST([to_tool_path_cmd])dnl This mistake of mine made it hard for me to understand why you had fleshed that out with all the other cases from the to_host case-tree. But of course you hadn't fleshed out anything, you wrote the cache check independently, and it looked so similar to my version (we both copied your to_host code) that I was confused. However, because I didn't pseudo-cherry-pick the patch which actually USES the new func_to_tool_path function...I didn't actually *break* anything in my build. Right, now I see. You have not included enough to make it matter. Sorry for the panic attack... But I can see that if you accepted my 07- patch, it would break your pre-existing USES of func_to_tool_path. However, the fix to my 07- patch is just a couple of one-liners, right? See above :-) *snip* The patches in pr-msvc-support and in my preview git tree are not independent, even when they touch the same area, for this reason: The patches *in* pr-msvc-support have been approved by some libtool maintainer (read: Ralf) (not counting the 4 patches that I pushed by mistake). Then there are patches waiting for review to get into the branch (or master), and lastly there are patches that depends on external patches not yet fully reviewed. So, three classes: a) in the branch (except 4 patches belonging in b) b) waiting for review c) depending on externals In the case of the AR patches there is, as you've discovered, patches in all of a, b and c. Also, when something has gone into the branch, I'm hesitant to change it. I feel that it is much better to just add patches on top in order to preserve history. This makes it harder to cherry-pick, of course. The complexities and the length of my patch queue is not all my fault. Believe me, noone would be happier than me if it wasn't such a mess. Cheers, Peter
Re: Suppressing --whole-archive
Hi Ralf, Ralf Wildenhues a écrit : [...] Do files /usr/lib/mysql/libmysqlclient.la and /usr/lib/mysql/libz.la exist, and if yes, could you please post their contents? Yes they exist. [...] OK, now I'm officially confused. Both of the libraries are not convenience archives (as indicated by the nonempty 'libdir' and 'installed' settings). So I still don't see where this whole archive thingy comes from. Could be one of the other libraries. But in order to be able to say for sure, I would need to look at the output of /bin/sh ../../libtool --tag=CXX --config as well as the output of the --mode=link command line above, with --debug added as first argument after ../../libtool. Please gzip this output, it will be large. I am not completely sure of what you asked in second (--mode=link) but here is what I did : /bin/sh ../../libtool --tag=CXX --config libtoolOutput1.txt /bin/sh ../../libtool --debug --tag=CXX --mode=link libtoolOutput2.txt 21 I would be pleased to send other information if that was not what you meant. I attached a tgz with the two files. Thanks, Ralf Thanks a lot, and have a nice week-end ! Barth -- Barthélémy von Haller barthelemy.von.hal...@cern.ch CERN PH-AID (ALICE DAQ) output.tgz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Suppressing --whole-archive
* Barthelemy von Haller wrote on Fri, Feb 27, 2009 at 03:22:51PM CET: Ralf Wildenhues a écrit : [...] I would need to look at the output of /bin/sh ../../libtool --tag=CXX --config as well as the output of the --mode=link command line above, with --debug added as first argument after ../../libtool. Please gzip this output, it will be large. I am not completely sure of what you asked in second (--mode=link) but here is what I did : /bin/sh ../../libtool --tag=CXX --config libtoolOutput1.txt /bin/sh ../../libtool --debug --tag=CXX --mode=link libtoolOutput2.txt 21 I would be pleased to send other information if that was not what you meant. The first is ok. For the second, I meant to see the output of the following long line, when run in the correct directory: /bin/sh ../../libtool --debug --mode=link g++ -fPIC -Wall -Wextra -Wshadow -Wredundant-decls -g -O2 -o libAmoreCore.la -rpath /opt/amore/lib -release 1.1 -L/local/root/lib -L/date/monitoring/Linux -lmonitor -L/usr/local/lib -lshift -L/date/db/Linux -lDb -L/date/infoLogger/Linux -lInfo -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lGui -pthread -lm -ldl -rdynamic -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc -lRMySQL CoreDict.lo StringUtility.lo Event.lo MOMessage.lo MonitorInterface.lo MonitorObject.lo MySQLServer.lo PoolInterface.lo RuntimeModule.lo SocketInterface.lo TDATEEventParser.lo Run.lo Session.lo LogBook.lo InfoLogger.lo RunControl.lo AmoreDA.lo AmoreDABackEnd.lo (and yes, both stdout and stderr in the same file please). You can probably get this output also with something like make rm -f libAmoreCore.la make libAmoreCore.la LIBTOOLFLAGS=--debug if you are using Automake = 1.10. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Suppressing --whole-archive
Hi, Ralf Wildenhues a écrit : * Barthelemy von Haller wrote on Fri, Feb 27, 2009 at 03:22:51PM CET: Ralf Wildenhues a écrit : [...] I would need to look at the output of /bin/sh ../../libtool --tag=CXX --config as well as the output of the --mode=link command line above, with --debug added as first argument after ../../libtool. Please gzip this output, it will be large. I am not completely sure of what you asked in second (--mode=link) but here is what I did : /bin/sh ../../libtool --tag=CXX --config libtoolOutput1.txt /bin/sh ../../libtool --debug --tag=CXX --mode=link libtoolOutput2.txt 21 I would be pleased to send other information if that was not what you meant. The first is ok. For the second, I meant to see the output of the following long line, when run in the correct directory: /bin/sh ../../libtool --debug --mode=link g++ -fPIC -Wall -Wextra -Wshadow -Wredundant-decls -g -O2 -o libAmoreCore.la -rpath /opt/amore/lib -release 1.1 -L/local/root/lib -L/date/monitoring/Linux -lmonitor -L/usr/local/lib -lshift -L/date/db/Linux -lDb -L/date/infoLogger/Linux -lInfo -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lGui -pthread -lm -ldl -rdynamic -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc -lRMySQL CoreDict.lo StringUtility.lo Event.lo MOMessage.lo MonitorInterface.lo MonitorObject.lo MySQLServer.lo PoolInterface.lo RuntimeModule.lo SocketInterface.lo TDATEEventParser.lo Run.lo Session.lo LogBook.lo InfoLogger.lo RunControl.lo AmoreDA.lo AmoreDABackEnd.lo (and yes, both stdout and stderr in the same file please). Ok, I have attached the output of the previous command. You can probably get this output also with something like make rm -f libAmoreCore.la make libAmoreCore.la LIBTOOLFLAGS=--debug if you are using Automake = 1.10. I did with the first method. Thanks, Ralf Cheers, Barth -- Barthélémy von Haller barthelemy.von.hal...@cern.ch CERN PH-AID (ALICE DAQ) libtoolOutput3.tgz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Suppressing --whole-archive
Hi again, sorry the second attachment was wrong. Here is the correct one. Cheers, Barth Ralf Wildenhues a écrit : * Barthelemy von Haller wrote on Fri, Feb 27, 2009 at 03:22:51PM CET: Ralf Wildenhues a écrit : [...] I would need to look at the output of /bin/sh ../../libtool --tag=CXX --config as well as the output of the --mode=link command line above, with --debug added as first argument after ../../libtool. Please gzip this output, it will be large. I am not completely sure of what you asked in second (--mode=link) but here is what I did : /bin/sh ../../libtool --tag=CXX --config libtoolOutput1.txt /bin/sh ../../libtool --debug --tag=CXX --mode=link libtoolOutput2.txt 21 I would be pleased to send other information if that was not what you meant. The first is ok. For the second, I meant to see the output of the following long line, when run in the correct directory: /bin/sh ../../libtool --debug --mode=link g++ -fPIC -Wall -Wextra -Wshadow -Wredundant-decls -g -O2 -o libAmoreCore.la -rpath /opt/amore/lib -release 1.1 -L/local/root/lib -L/date/monitoring/Linux -lmonitor -L/usr/local/lib -lshift -L/date/db/Linux -lDb -L/date/infoLogger/Linux -lInfo -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lGui -pthread -lm -ldl -rdynamic -rdynamic -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc -lRMySQL CoreDict.lo StringUtility.lo Event.lo MOMessage.lo MonitorInterface.lo MonitorObject.lo MySQLServer.lo PoolInterface.lo RuntimeModule.lo SocketInterface.lo TDATEEventParser.lo Run.lo Session.lo LogBook.lo InfoLogger.lo RunControl.lo AmoreDA.lo AmoreDABackEnd.lo (and yes, both stdout and stderr in the same file please). You can probably get this output also with something like make rm -f libAmoreCore.la make libAmoreCore.la LIBTOOLFLAGS=--debug if you are using Automake = 1.10. Thanks, Ralf -- Barthélémy von Haller barthelemy.von.hal...@cern.ch CERN PH-AID (ALICE DAQ) libtoolOutput4.tgz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking together .dll using .a static libraries
LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be x86 archive import or x86 DLL, but not x86 archive static. Some of those libraries are always linked as example mingwex. Also you may pass flags to the linker: -Wl... Libtool pass it to the linker, i.e. you may pass def-file or library (-lXXX) . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
