func_convert_file_cygwin_to_w32 woes
I am trying to build a program under cygwin but using the mingw tool chain in a fake cross build way. In my configure environment, I have: export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 as suggested by the libtool manual. I'm using libtool 2.4. Everything goes smoothly until install time when libtool calls ranlib (the mingw one) on an absolute path and of course the cygwin absolute path doesn't make sense to the mingw ranlib. I thought that's what the func_convert... bit was for. A full understanding of libtool internals escapes me. Is there something else I should be doing or can anyone suggest good ways to troubleshoot this? Thanks -Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: func_convert_file_cygwin_to_w32 woes
On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
> Hi Dan,
>
> * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
>> I am trying to build a program under cygwin but using the mingw tool
>> chain in a fake cross build way. In my configure environment, I have:
>>
>> export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>>
>> as suggested by the libtool manual. I'm using libtool 2.4.
>>
>> Everything goes smoothly until install time when libtool calls ranlib
>> (the mingw one) on an absolute path and of course the cygwin absolute
>> path doesn't make sense to the mingw ranlib. I thought that's what the
>> func_convert... bit was for.
>
> Please copy and paste 'libtool --mode={link,relink,install}' commands
> for the libraries and programs involved. We may provide better help
> then.
attached.
LINK
/bin/sh ../libtool --tag=CC --mode=link mingw32-gcc
-DBACKEND_DIR='"/home/dan/src/gerbv/gerbv_inst/share/gerbv/scheme/"'
-DSCMSUBDIR='"scheme"' -mms-bitfields -mwindows -Wall -mms-bitfields
-Ic:/cygwin/home/dan/gtk_win32/include/gtk-2.0
-Ic:/cygwin/home/dan/gtk_win32/lib/gtk-2.0/include
-Ic:/cygwin/home/dan/gtk_win32/include/atk-1.0
-Ic:/cygwin/home/dan/gtk_win32/include/cairo
-Ic:/cygwin/home/dan/gtk_win32/include/gdk-pixbuf-2.0
-Ic:/cygwin/home/dan/gtk_win32/include/pango-1.0
-Ic:/cygwin/home/dan/gtk_win32/include/glib-2.0
-Ic:/cygwin/home/dan/gtk_win32/lib/glib-2.0/include
-Ic:/cygwin/home/dan/gtk_win32/include
-Ic:/cygwin/home/dan/gtk_win32/include/freetype2
-Ic:/cygwin/home/dan/gtk_win32/include/libpng14-mms-bitfields
-Ic:/cygwin/home/dan/gtk_win32/include/cairo
-Ic:/cygwin/home/dan/gtk_win32/include/glib-2.0
-Ic:/cygwin/home/dan/gtk_win32/lib/glib-2.0/include
-Ic:/cygwin/home/dan/gtk_win32/include
-Ic:/cygwin/home/dan/gtk_win32/include/freetype2
-Ic:/cygwin/home/dan/gtk_win32/include/libpng14-version-info 1:5:0
-no-undefined -o libgerbv.la -rpath /home/dan/src/gerbv/gerbv_inst/lib
amacro.lo tooltable.lo draw.lo draw-gdk.lo drill.lo exportimage.lo gerb_file.lo
gerb_image.lo gerber.lo gerbv.lo pick-and-place.lo csv.lo gerb_stats.lo
drill_stats.lo export-rs274x.lo export-drill.lo -lm
-Lc:/cygwin/home/dan/gtk_win32/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0
-lgio-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl
-Lc:/cygwin/home/dan/gtk_win32/lib -lcairo
libtool: link: mingw32-gcc -shared .libs/amacro.o .libs/tooltable.o
.libs/draw.o .libs/draw-gdk.o .libs/drill.o .libs/exportimage.o
.libs/gerb_file.o .libs/gerb_image.o .libs/gerber.o .libs/gerbv.o
.libs/pick-and-place.o .libs/csv.o .libs/gerb_stats.o .libs/drill_stats.o
.libs/export-rs274x.o .libs/export-drill.o -Lc:/cygwin/home/dan/gtk_win32/lib
-lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lpangowin32-1.0 -lgdi32
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lglib-2.0 c:/mingw/lib/libintl.dll.a -L/mingw/lib
/mingw/lib/libiconv.dll.a -lcairo -mms-bitfields -mwindows -mms-bitfields
-mms-bitfields -o .libs/libgerbv-1.dll -Wl,--enable-auto-image-base -Xlinker
--out-implib -Xlinker .libs/libgerbv.dll.a
Creating library file: .libs/libgerbv.dll.a
libtool: link: ar cru .libs/libgerbv.a amacro.o tooltable.o draw.o draw-gdk.o
drill.o exportimage.o gerb_file.o gerb_image.o gerber.o gerbv.o
pick-and-place.o csv.o gerb_stats.o drill_stats.o export-rs274x.o export-drill.o
libtool: link: ranlib .libs/libgerbv.a
libtool: link: ( cd ".libs" && rm -f "libgerbv.la" && ln -s "../libgerbv.la"
"libgerbv.la" )
[ snip ]
INSTALL
test -z "/home/dan/src/gerbv/gerbv_inst/lib" || /usr/bin/mkdir -p
"/home/dan/src/gerbv/gerbv_inst/lib"
/bin/sh ../libtool --mode=install /usr/bin/install -c libgerbv.la
'/home/dan/src/gerbv/gerbv_inst/lib'
libtool: install: /usr/bin/install -c .libs/libgerbv.dll.a
/home/dan/src/gerbv/gerbv_inst/lib/libgerbv.dll.a
libtool: install: base_file=`basename libgerbv.la`
libtool: install: dlpath=`/bin/sh 2>&1 -c '. .libs/'libgerbv.la'i; echo
libgerbv-1.dll'`
libtool: install: dldir=/home/dan/src/gerbv/gerbv_inst/lib/`dirname
../bin/libgerbv-1.dll`
libtool: install: test -d /home/dan/src/gerbv/gerbv_inst/lib/../bin || mkdir
-p /home/dan/src/gerbv/gerbv_inst/lib/../bin
libtool: install: /usr/bin/install -c .libs/libgerbv-1.dll
/home/dan/src/gerbv/gerbv_inst/lib/../bin/libgerbv-1.dll
libtool: install: chmod a+x
/home/dan/src/gerbv/gerbv_inst/lib/../bin/libgerbv-1.dll
libtool: install: if test -n '' && test -n 'strip --strip-unneeded'; then eval
'strip --strip-unneeded
/home/dan/src/gerbv/gerbv_inst/
Re: func_convert_file_cygwin_to_w32 woes
On 1/4/2011 11:44 AM, Peter Rosin wrote:
> Den 2011-01-04 05:39 skrev Dan McMahill:
>> On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
>>> Hi Dan,
>>>
>>> * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
>>>> I am trying to build a program under cygwin but using the mingw tool
>>>> chain in a fake cross build way. In my configure environment, I have:
>>>>
>>>> export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>>>>
>>>> as suggested by the libtool manual. I'm using libtool 2.4.
>>>>
>>>> Everything goes smoothly until install time when libtool calls ranlib
>>>> (the mingw one) on an absolute path and of course the cygwin absolute
>>>> path doesn't make sense to the mingw ranlib. I thought that's what the
>>>> func_convert... bit was for.
>>>
>>> Please copy and paste 'libtool --mode={link,relink,install}' commands
>>> for the libraries and programs involved. We may provide better help
>>> then.
>>
>> attached.
>
> Ok, I found a couple of minutes to look at this. Can you check if this
> patch helps?
>
> (It still needs a ChangeLog etc...)
>
> Cheers,
> Peter
>
I'm not running a git version but applying the patch to the libtool-2.4
I was using worked. This seems to address the problem.
Many thanks.
-Dan
___
http://lists.gnu.org/mailman/listinfo/libtool
libtool wrapper env variable
Hello, I helped out with a a build system and switching to libtool for a shared library and am now having the following problem. After building but before installing, the program used to be able to be tested by cd foo-x.y/src ./myprog Unfortunately, myprog was keying off of the directory part of argv[0] to help find a file which must be read when the program runs but now argv[0] includes .libs/ due to libtool. There is an environment variable which can be set that will tell myprog to look somewhere else for this file. Is there anyway to cause the libtool wrapper script, src/myprog, to set this variable automatically? If not, any suggestions on the best way to deal with programs which might use the directory of argv[0] when testing with the libtool generated wrapper script? I guess I could add my own wrapper that calls the libtool wrapper and add the variable there but that seems like a hack. I could also modify myprog to strip a trailing /.libs/ in the directory part of argv[0]. Thoughts? Thanks -Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
problems with LD_LIBRARY_PATH and libtool wrapper
Hello, I have a problem with the LD_LIBRARY_PATH handling inside of the libtool wrapper. I see a line like: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/pkg/lib:/home/dan/src/myprog/libmine/.libs:$LD_LIBRARY_PATH" in /home/dan/src/myprog/src/myprog which is the libtool wrapper. The problem is I may have an out of date libmine installed in /usr/pkg/lib and at runtime I pick that one up instead of the one in /home/dan/src/myprog/libmine/.libs. This has caused me great confusion a couple of times when I absolutely could not correlate the behavior of the program with the sources in ../libmine because of course they didn't match. It seems that we want to make sure any ".libs" directories appear first in LD_LIBRARY_PATH. Am I missing something obvious here? Thanks -Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool wrapper env variable
Bruce Korb wrote: make LDFLAGS=-static You'll get a real binary, but statically incorporate libraries from the build tree. I guess this can be used for my question about LD_LIBRARY_PATH although it seems this problem will show up for lots of folks. Could this just be a problem with incorrect versioning of the libtool library? I.e. if I changed a version somewhere would libtool or the run time linker be smart enough to always pick out the current library? But this answer belongs in the other thread since it is not related to the question in this thread (which was how to set some arbitrary environment variable automatically in the libtool wrapper script). Thanks! -Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool wrapper env variable
Bruce Korb wrote: But this answer belongs in the other thread since it is not related to the question in this thread (which was how to set some arbitrary environment variable automatically in the libtool wrapper script). There isn't such a thing. If you fully link, then you don't need the "LD_LIBRARY_PATH" hack. By the way, I tried that, too. That wound up having other breakage because various tools simply know that users are not supposed to mess with it. Linking with -static is the path of least resistance. Good luck. Regards, Bruce right but my other question was a completely different issue than the LD_LIBRARY_PATH one ;) It was for a variable that has a special meaning only to the particular program in question and not the linker. -Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problems with LD_LIBRARY_PATH and libtool wrapper
Ralf Wildenhues wrote: Hi Dan, * Dan McMahill wrote on Wed, Aug 13, 2008 at 11:06:41PM CEST: I have a problem with the LD_LIBRARY_PATH handling inside of the libtool wrapper. I see a line like: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/pkg/lib:/home/dan/src/myprog/libmine/.libs:$LD_LIBRARY_PATH" in /home/dan/src/myprog/src/myprog which is the libtool wrapper. The problem is I may have an out of date libmine installed in /usr/pkg/lib and at runtime I pick that one up instead of the one in /home/dan/src/myprog/libmine/.libs. This has caused me great confusion a couple of times when I absolutely could not correlate the behavior of the program with the sources in ../libmine because of course they didn't match. It seems that we want to make sure any ".libs" directories appear first in LD_LIBRARY_PATH. Am I missing something obvious here? Could be. Does myprog have an myprog_LDADD = ../libmine/libmine.la myprog_LDADD = @LIBMINE_LDADD@ and at configure time @LIBMINE_LDADD@ either gets set to ../libmine/libmine.la or something like -L/usr/pkg/lib -lmine. There is a configure time option that says to either use a local build of the library or use an already installed one. This was done because there are actually about 5 different programs that all use libmine that are all included in the tarball. This lets a third party packaging system add the individual programs more easily. The programs are all just different front ends (gtk, cgi, commandline, scilab, octave, etc) to libmine. One thing I have realized is I do not have any version set for libmine which is clearly not a good thing. line, and can you show the libtool link command lines for both the library and the program plus all of their output when executed? Here is the link lines for the library (libwcalc) /bin/ksh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -o libwcalc.la -rpath /usr/local/lib air_coil.lo air_coil_loadsave.lo bars.lo bars_loadsave.lo coax.lo coax_loadsave.lo coplanar.lo coplanar_loadsave.lo coupled_microstrip.lo coupled_microstrip_loadsave.lo coupled_stripline.lo coupled_stripline_loadsave.lo defaults.lo ic_microstrip.lo ic_microstrip_loadsave.lo mathutil.lo microstrip.lo microstrip_loadsave.lo misc.lo stripline.lo stripline_loadsave.lo units.lo wcalc_loadsave.lo -lm gcc -shared .libs/air_coil.o .libs/air_coil_loadsave.o .libs/bars.o .libs/bars_loadsave.o .libs/coax.o .libs/coax_loadsave.o .libs/coplanar.o .libs/coplanar_loadsave.o .libs/coupled_microstrip.o .libs/coupled_microstrip_loadsave.o .libs/coupled_stripline.o .libs/coupled_stripline_loadsave.o .libs/defaults.o .libs/ic_microstrip.o .libs/ic_microstrip_loadsave.o .libs/mathutil.o .libs/microstrip.o .libs/microstrip_loadsave.o .libs/misc.o .libs/stripline.o .libs/stripline_loadsave.o .libs/units.o .libs/wcalc_loadsave.o -lm -Wl,-soname -Wl,libwcalc.so.0 -o .libs/libwcalc.so.0.0 (cd .libs && rm -f libwcalc.so.0 && ln -s libwcalc.so.0.0 libwcalc.so.0) (cd .libs && rm -f libwcalc.so && ln -s libwcalc.so.0.0 libwcalc.so) ar cru .libs/libwcalc.a air_coil.o air_coil_loadsave.o bars.o bars_loadsave.o c oax.o coax_loadsave.o coplanar.o coplanar_loadsave.o coupled_microstrip.o coupled_microstrip_loadsave.o coupled_stripline.o coupled_stripline_loadsave.o defaults.o ic_microstrip.o ic_microstrip_loadsave.o mathutil.o microstrip.o microstrip_loadsave.o misc.o stripline.o stripline_loadsave.o units.o wcalc_loadsave.o ranlib .libs/libwcalc.a creating libwcalc.la (cd .libs && rm -f libwcalc.la && ln -s ../libwcalc.la libwcalc.la) and here is the link for the program: /bin/ksh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wl,-R/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/pkg/lib -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lXi -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lXrandr -lXext -lXcursor -lXfixes -lcairo -lpangoft2-1.0 -lfontconfig -lfreetype -lz -lpango-1.0 -lm -lXrender -lX11 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -o wcalc about.o alert.o air_coil_gui.o bars_gui.o coax_gui.o coplanar_gui.o coupled_microstrip_gui.o coupled_stripline_gui.o epscat.o files.o gtk-units.o ic_microstrip_gui.o menus.o microstrip_gui.o print.o start.o stripline_gui.o version.o wcalc.o AWG.o permeability.o permitivity.o resistivity.o units.o ../lib wcalc/libwcalc.la -lm mkdir .libs gcc -g -O2 -Wall -Wl,-R/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib -Wl,-R/usr/X11R6/lib -o .libs/wcalc about.o alert.o air_coil_gui.o bars_gui.o coax_gui.o coplanar_gui.o coupled_microstrip_gui.o coupled_stripline_gui.o epscat.o files.o gtk-units.o ic_microstrip_gui.o menus.o microstrip_gui.o print.o start.o stripline_gui.o version.o wcalc.o AWG.o permeability.o permitivity.o resistivity.o units.o -L/usr/pkg/lib -L/usr/X11R6/lib /usr/pkg/lib/libgtk-x11-2.0.so /usr/pkg/lib/libgdk-x
Re: problems with LD_LIBRARY_PATH and libtool wrapper
Ralf Wildenhues wrote:
My analysis was at least partly wrong:
* Ralf Wildenhues wrote on Thu, Aug 21, 2008 at 08:37:37AM CEST:
* Dan McMahill wrote on Wed, Aug 20, 2008 at 03:55:19AM CEST:
/bin/ksh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall
-Wl,-R/usr/pkg/lib
-Wl,--rpath -Wl,/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/pkg/lib
Here's your problem: something adds
-Wl,-R/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib
to the link line of your program. Find out what that is, probably
either some flag in your Makefile.am or a configure macro.
[...]
I'm still wondering whether this is a bug in libtool though.
Namely:
If the user passes run paths with -R to libtool, should these run paths
be reordered to always appear _after_ those run paths added by libtool
which point to uninstalled locations?
If the user passes run paths with -R to libtool, then they _are_ already
put after all uninstalled run paths. So this bug does not exist.
The issue then is one of users passing in run paths via other methods,
e.g., '-Wl,-R' or '-Wl,--rpath'. Actually, there are two issues here:
First, the one Dan reported. Second, the fact that it is not portable
to do so. Even if the instance that added those paths would take care
to substitute the right system-specific linker flag, then there are
systems which allow only one such flag on the command line (with run
paths separated by colon or so). So libtool _has_ to mangle them any
way.
We could just decree that passing -Wl,-rpath and the like to libtool is
not allowed, and one should always pass with -R. Then the fix would be
a documentation clarification one only.
So, for you, Dan, that would mean tracking down whatever macro sets
those flags, and getting it to pass -R to libtool instead. Or better
even not passing that: at least if the aim is to link against some
installed libraries, if those are libtool libraries, they should just
be listed as /foo/bar/libfoo.la.
ok. It looks like it is coming from
pkg-config --libs gtk+-2.0
which is called by way of PKG_CHECK_MODULES. There is a
/usr/pkg/lib/libgtk.la but thats not what pkg-config puts out. I'm
thinking thats because the .la is only useful if you're using libtool
for linking.
I guess what I don't see is why the libtool wrapper script doesn't do this:
LD_LIBRARY_PATH="/path/to/libmine/.libs:${LD_LIBRARY_PATH}:/usr/pkg/lib"
instead of
LD_LIBRARY_PATH="/usr/pkg/lib:/path/to/libmine/.libs:${LD_LIBRARY_PATH}"
In other words it seems like we always want our local .libs directory to
come before other stuff and we might want to make our LD_LIBRARY_PATH
setting from the environment come before a system path.
-Dan
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: problems with LD_LIBRARY_PATH and libtool wrapper
Ralf Wildenhues wrote: and at configure time @LIBMINE_LDADD@ either gets set to ../libmine/libmine.la or something like -L/usr/pkg/lib -lmine. OK. First tangential issue: if you use @substitutions@ rather than Makefile.am conditionals, then automake cannot see through them, and you have to fix dependencies yourself. IOW, you have to ensure that myprog_DEPENDENCIES contains '../libmine/libmine.la' if myprog_LDADD contains it. In contrast, automake can figure it out itself with if LOCAL_LIBMINE myprog_LDADD = ../libmine/libmine.la else myprog_LDADD = ... endif This issue isn't your actual problem though. Thanks. I've changed to use automake conditionals here like you suggested. -Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
