Compiling with MinGW
This is not exactly a bug in a strict since but it is a complication of building software with MinGW. Just a little back ground I was looking to build the latest version of wvware so that I end up with a windows stand alone binary. The environment that I was working on was: Windows 2003 Cygwin Current (make, pkgconfig, autoconf, automake) Installed MingGW using auto installer MinGW-5.0.3 Given the above I downloaded and built each of the following: zlib-1.2.3.tar.gz http://www.zlib.net/zlib-1.2.3.tar.gz libiconv-1.11.tar.gz http://mirrors.usc.edu/pub/gnu/libiconv/ libiconv-1.11.tar.gz libxml2-2.6.26.tar.gz ftp://xmlsoft.org/libxml2/libxml2-2.6.26.tar.gz gettext-0.15.tar.gz http://mirrors.usc.edu/pub/gnu/gettext/ gettext-0.15.tar.gz glib-2.12.1.tar.gzftp://ftp.gtk.org/pub/gtk/v2.12/glib-2.12.1.tar.gz libgsf-1.14.1.tar.gz http://ftp.gnome.org/pub/GNOME/sources/libgsf/ 1.14/libgsf-1.14.1.tar.gz wv-1.2.1.tar.gz http://prdownloads.sourceforge.net/wvware/ wv-1.2.1.tar.gz?download I was able to get everything to work out in the end however gettext and glib packages both gave me difficulties. The errors they generated are: GETTEXT: Making all in libuniname make[3]: Entering directory `/home/matthew/tmp/wv/gettext-0.15/ gettext-tools/libuniname' /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Lc:/progra~1/wv -Wl,--disable-auto-import -o test-names.exe test-names.o libuniname.a ../lib/libgettextlib.la gcc -g -O2 -Wl,--disable-auto-import -o .libs/test-names.exe test- names.o -Lc:/progra~1/wv libuniname.a ../lib/.libs/ libgettextlib.dll.a /home/matthew/tmp/wv/gettext-0.15/gettext-tools/ intl/.libs/libintl.dll.a -Lc:/progra~1/wv/lib gcc.exe: /home/matthew/tmp/wv/gettext-0.15/gettext-tools/intl/.libs/ libintl.dll.a: No such file or directory make[3]: *** [test-names.exe] Error 1 make[3]: Leaving directory `/home/matthew/tmp/wv/gettext-0.15/gettext- tools/libuniname' GLIB: Making all in gobject make[2]: Entering directory `/home/matthew/tmp/wv/glib-2.12.1/gobject' make all-am make[3]: Entering directory `/home/matthew/tmp/wv/glib-2.12.1/gobject' /bin/sh ../libtool --mode=link gcc -g -O2 -mms-bitfields -Wall -Lc:/ progra~1/wv/lib -o gobject-query.exe gobject-query.o ./ libgobject-2.0.la ../glib/libglib-2.0.la -lintl gcc -g -O2 -mms-bitfields -Wall -o .libs/gobject-query.exe gobject- query.o -Lc:/progra~1/wv/lib ./.libs/libgobject-2.0.dll.a /home/ matthew/tmp/wv/glib-2.12.1/glib/.libs/libglib-2.0.dll.a ../glib/.libs/ libglib-2.0.dll.a -lws2_32 -lole32 c:/progra~1/wv/lib/libintl.dll.a c:/progra~1/wv/lib/libiconv.dll.a -Lc:/progra~1/wv/lib gcc.exe: /home/matthew/tmp/wv/glib-2.12.1/glib/.libs/ libglib-2.0.dll.a: No such file or directory make[3]: *** [gobject-query.exe] Error 1 make[3]: Leaving directory `/home/matthew/tmp/wv/glib-2.12.1/gobject' Both of the above errors are caused because of the environment the software is being built in and how libtool interacts. The basic problem is gcc for MinGW does not know how to properly handle cygwin paths. libtool is automatically generating a fully qualified path using cygwin based paths. I didn't spend a lot of time digging into what the right solution for libtool might be but found that by simply editing the libtool used in both of the above cases and adding: case $deplib in /home*) deplib="c:/cygwin"$deplib;; esac just after the for loop on line 2459 gettext and line 2363 of glib (that area looks something like this) if test "$pass" = dlopen; then # Collect dlpreopened libraries save_deplibs="$deplibs" deplibs= fi for deplib in $libs; do# right after this line. lib= found=no case $deplib in I was able to complete the compiles and generate a version of wvware-1.2.1 that worked standalone on windows. If a good option can be found to make this issue go away it would be nice but it is a somewhat unusual configuration. But, I thought I would pass it along just in case someone else might be interested. Matthew McGillis ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling with MinGW
Exactly. Did you compile GCC yourself but installed it in MSYS /bin? I think that was the thing not to do, as it inhibits the automatic path translation. See http://www.mingw.org/mingwfaq.shtml#faq-usingwithmsys for more info. The gcc used comes from mingw. I installed MinGW by Downloading the auto installer at http:// prdownloads.sourceforge.net/mingw/MinGW-5.0.3.exe?download: Ran program and installed mingw and c++ support. By default this places gcc in c:/mingw/bin . I'm not using MSYS at all. I'm using MinGW for the compilers and cygwin for the shell and basic tools. In my path I have added / cygdrive/c/mingw/bin as the first item in my PATH. If that wasn't the case, then I'd like more information, such as how and where you installed GCC, its version, and '../libtool --version'. gcc -v Reading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu- as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads -- disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable- win32-registry --disable-shared --enable-sjlj-exceptions --enable- libgcj --disable-java-awt --without-x --enable-java-gc=boehm -- disable-libgcj-debug --enable-interpreter --enable-hash- synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) For my compiles: gettext-0.15/gettext-tools/libtool --version ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. glib-2.12.1/libtool --version ltmain.sh (GNU libtool) 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Matthew ___ http://lists.gnu.org/mailman/listinfo/libtool
Come as much as a pr0n star! upto 500% more!
Title: I want a lagoon in my backyard It is hard to decipher Mia's writing. S.URPRISE YOUR L.OVER TODAY! BE HAPPY WHEN YOU MAKE L.OVE! How w.ould you like a MUCH B.IGGER P.EN1S? Gai.n upto 3-4 i.nches!! ADD 3 IN.CHES IN LENGTH! G.A.I.N AN EXTRA 20% IN T.H.I.CKNESS! PRODUCE ST.RONGER E.RECT1ONS! HAVE M.ORE INTENSE 0.RGASMS! HAVE A STRONGER 5.EXUAL DESIRE! 1.NCREASED S.E..XUAL STAMINA! FULLY DO.CTOR APP.ROVED! L.EARN MORE! 100% MON.EY BAC.K SATISF.ACTION GUA.RANTEE! 7705ks735147d7q93lnh8gkg272423e609b634958480f07h655g7e54p0467536j124t710dn023i9j889r24872b790769l551814nf63m6kl59f2857fb43b039926464g43y40z6awn82I want a lagoon in my backyardIt is hard to decipher Mia's writing.hje5cgd16d3y2a59682i1817329c9yh655g7e54p0467536j124t710dn023i9j889r24872b790769l551814nf63m6kl59f2857fb43b039926464g To be r3m0v3d from our list, Here ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Fix: Interlibrary dependencies SCO Uw7
Hello Goodly Folks, Thank you for all your work on making libtool so portable and necessitating that I learn how to spell dependencies :o) I recently had the chance to compile libtool-1.3.5 for my SCO UnixWare 7.1.1 box, often referred to as an i586-sco-sysv5uw7.1.1 Very nice. I've been furiously compiling programs and libraries for the last few months. I finally learned enough to understand the warnings I was getting from libtool that Interlibrary Dependencies were not known to be supported and that libtool was dropping them. You know the one. The end all of this is that it's my belief that Interlibrary dependencies are well supported, and I'd like to get a peer review of the following fix. I checked out the CVS libtool today, 17 Apr 2001. It looks like one small additional case listing in libtool.m4 should make it work for Uw7. First comes your check to see if my host is sysv5*, then comes my test for the vendor part, which in this instance, is sco. Here's what I did. $ gdiff -U 4 libtool.m4.orig libtool.m4 --- libtool.m4.orig Tue Apr 17 16:07:01 2001 +++ libtool.m4 Tue Apr 17 16:12:21 2001 @@ -3180,8 +3180,11 @@ ;; ncr) lt_cv_deplibs_check_method=pass_all ;; + sco) +lt_cv_deplibs_check_method=pass_all +;; sequent) lt_cv_file_magic_cmd='/bin/file' [lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )'] ;; I hope I didn't suppose too much nor do the wrong thing here. I appreciate your feedback. Matt Schalit === Btw, -lc is not the sort of library you add to Uw7 either, as Boyd helped me to learn. However, I helped Boyd to learn that wu-ftpd 2.6.1 needs to compile on Uw7 using SCO's cc and -lc, in the absence of SCO's UDK. It will segfault otherwise. So -lc is not well received, but there is a time when it's used. I have no idea if that has any bearing on your discussions here about -lc, but I thought I'd throw that out there. If a maintainer wants an account on my Uw7 box to poke around, I can help you out if you email me privately. = ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Missing header on Uw7
Hi Folks, On SCO UnixWare 7.1.1, the header file is found as . I just checked out CVS libtool today, and it looks like I'll have to change a few files: $ find . | xargs fgrep -l "dl.h" ./ChangeLog.0 ./ChangeLog ./ltdl.m4 ./doc/libtool.texi ./libltdl ./libltdl/CVS/Entries ./libltdl/Makefile.am ./libltdl/ltdl.c ./libltdl/ltdl.h ./mail/c++ ./mdemo/Makefile.am ./mdemo/main.c Should I just do that, or is there a better way? Thanks, Matt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix: Interlibrary dependencies SCO Uw7
"Gary V. Vaughan" wrote: > > On Wednesday 18 April 2001 1:06 am, Matthew Schalit wrote: Hi Gary, Thanks for the followup. > If you are sure that it is okay to link non-PIC objects from a static archive > into a shared library, then this is the right thing to do. You can test this > by manually linking a shared lib with a static archive, and then trying to > run an application linked against only the new shared library, but that > relies on a symbol from the static archive. If you can confirm that this > works, I'll commit your patch. Does the fact that the libtool passes all 83 tests, including the deplib.test file mean that we're good? If it's not enough, I can post to comp.unix.sco.programmer and see if one of the SCO engineers has a definitive answer. I already had one of them show me how to do a dump -Lv /lib/libjava.so sort of command to see the NEEDED lines which supposedly are evidence of an interlibrary dependency. I'm not sure I have enough knowhow to create a test by hand otherwise. Thanks, Matt > Gary ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix: Interlibrary dependencies SCO Uw7
"Gary V. Vaughan" wrote: > > > > If you are sure that it is okay to link non-PIC objects from a static > > > archive into a shared library, then this is the right thing to do. Hi Folks, I got an answer from comp.unix.sco.programmer. Matt Schalit <[EMAIL PROTECTED]> wrote: : [...] now I would like to know if these interlibrary : dependencies are supported on all 7.x.x. Yes, and in UnixWare 2, and in the upcoming Open UNIX 8.0.0 as well. :> "Gary V. Vaughan" wrote: :> If you are sure that it is okay to link non-PIC objects from :> a static archive into a shared library, Yes, you can do this. (On SCO OpenServer this will not work at all, but on all UnixWare and Open UNIX it will.) You will lose some performance doing this, since the pages that contain non-PIC code will be replicated for each process using them instead of being shared, but it will work correctly. :> You can test this by manually linking :> a shared lib with a static archive, and then trying to run :> an application linked against only the new shared :> library, but that relies on a symbol from the static :> archive. Yes, you should be able to successfully do this test. -- Jonathan Schilling SCO, Inc. [EMAIL PROTECTED] Based on that, I'm not comfortable with my patch. As I mentioned, UnixWare 7.x.x is identified as an i586-sco-sysv5uw7.x.x and my patch is caught by the sysv) option, then the sco) option. But I don't know how to adjust this for UnixWare 2.1.3, though. Thanks, Matthew ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix: Interlibrary dependencies SCO Uw7
"Gary V. Vaughan" wrote: > > Well, I don't know which combinations of triplets we need to accept and > reject for pass_all deplibs, so this could probably use some tweaking... but > the attached patch is the sort of thing you are looking for I think. Let me > know asap so we can get this in before 1.4 tomorrow. > > Cheers, > Gary. Hi Gary, I gave your patch a try and it didn't work correctly in the end, which was odd. Here's what happened: gpatch < 2001-04-21-gvv-uw-deplibs-passall.patch patching file libtool.m4 Then I checked libtool.m4, and it was patched, and the patch looked identical to what was in the .patch file. Then I ran ./bootstrap. Then I looked at configure, and the patch was corrupted. The square brackets were missing: case $host in *-sco-sysv5uw78* | *-sco-sysv4*uw2*) lt_cv_deplibs_check_method=pass_all ;; esac I think that's a feature, though. So you could fix yours. Or I could suggest this patch, which bypasses the square bracket problem. This patch also would go in a different place than the one you suggested, up a few lines. --- libtool.m4.orig Sat Apr 21 13:26:45 2001 +++ libtool.m4 Sat Apr 21 13:27:59 2001 @@ -3234,6 +3234,10 @@ lt_cv_file_magic_test_file=/lib/libc.so ;; +sysv5uw7* | sysv5uw8* | sysv4*uw2*) + lt_cv_deplibs_check_method=pass_all + ;; + sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*) case $host_vendor in motorola) ----- Thanks again, Matthew ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Missing header on Uw7
"Gary V. Vaughan" wrote:
>
> On Wednesday 18 April 2001 1:25 am, Matthew Schalit wrote:
> > Hi Folks,
>
> Hi Matt,
>
> Sorry for the slow response.
Np. I'm sure you're busy.
Your patch worked.
Yes, the dlopen API is available.
The only other thing I noticed was this section in libltdl/configure:
---
echo "$as_me:7795: checking whether deplibs are loaded by dlopen" >&5
echo $ECHO_N "checking whether deplibs are loaded by dlopen... $ECHO_C" >&6
if test "${libltdl_cv_sys_dlopen_deplibs+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
# PORTME does your system automatically load deplibs for dlopen()?
libltdl_cv_sys_dlopen_deplibs=unknown
case "$host_os" in
linux*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
netbsd*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
solaris*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
esac
fi
I noticed that I got an unknown from this. I don't understand what it's
checking for, so I don't know how to ask about it or fix it.
I went ahead an checked out CVS just now, and patched it with
your patch and mine for the pass_all part, and libtool compiled
and passed all 83 tests.
> Once again, a prompt reply gets your fix into libtool-1.4 tomorrow...
Sweet.
Matthew
> > Thanks,
> > Matt
>
> Cheers,
> Gary.
> --
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Libtool 1.4a i586-sco-sysv5uw7.1.1
Hi folks, Two results here, one with gcc, one without. No UDK with either test. i586-sco-sysv5uw7.1.1 gcc 2.95.3 binutils 2.10.1 gnu-make 3.79.1 autoconf 2.49e automake 1.4c no UDK ./bootstrap ./configure --with-gnu-ld Configuring libtool 1.4a (1.923 2001/04/25 01:01:22) ... gmake gmake check ... === All 83 tests passed === i586-sco-sysv5uw7.1.1 SCO cc SCO linker ld gnu-make 3.79.1 autoconf 2.49e automake 1.4c no UDK ./bootstrap ./configure --with-gnu-ld Configuring libtool 1.4a (1.923 2001/04/25 01:01:22) ... gmake gmake check ... FAIL: depdemo-make.test FAIL: mdemo-make.test FAIL: dryrun.test FAIL: depdemo-make.test FAIL: depdemo-make.test FAIL: mdemo-make.test ... 6 of 72 tests failed Thanks, Matt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool-1.4 -- libltdl_cv_sys_dlopen_deplibs=yes on Uw7
Hi folks, I had this discussion with Gary on this list a week or so ago. Does UnixWare 7.x.x load deplibs, or does libltdl have to do so... Trying to build libtool-1.4. I got an answer back from comp.unix.sco.programmer. In summary, I think Dave Prosser, from SCO, trys to explain that the anwer is yes, even though what he said was a bit convoluted. Here's the ng thread, where: > > == Matt Schalit >== Gary Vaughn == Dave Prosser - > On Saturday 21 April 2001 10:02 pm, Matthew Schalit wrote: > > The only other thing I noticed was this section in libltdl/configure: > > > > # PORTME does your system automatically load deplibs for dlopen()? > > libltdl_cv_sys_dlopen_deplibs=unknown > > case "$host_os" in > > linux*) > > libltdl_cv_sys_dlopen_deplibs=yes > > ;; > > netbsd*) > > libltdl_cv_sys_dlopen_deplibs=yes > > ;; > > solaris*) > > libltdl_cv_sys_dlopen_deplibs=yes > > ;; > > esac As a general rule, UnixWare and Solaris have common roots here and thus should act the same. > > I noticed that I got an unknown from this. I don't understand what it's > > checking for, so I don't know how to ask about it or fix it. Presumably the owner of the configure script should be told to include UnixWare in the list of "yes"s. > Setting this variable to yes tells libltdl that if a dlopened library > depends an another unloaded library that the OS takes care > of loading the deplib too. > > For instance, if I use libltdl to load libgtk.so into my app, will the > OS also load libgdk, libglib, libX11 etc for me? > > If the variable is not set to yes, libltdl will dlopen() those > libraries for me (and recursively any of their deplibs) before > trying to perform the dlopen actually asked for. Needless to > say this slows down dlopening a lot, especially when it is > not needed. If a dynamic library has DT_NEEDED entries for other dynamic libraries (see dump -Lv output), then they are *required* to be present before the original dynamic library can be completely loaded. That's what the dependency means. If the depended-on libraries have initialization routine(s) -- also listed in the dump -Lv output -- they need to be run before any initialization of the original library. If the dependent libraries have already been included in the process, the dynamic linker just points to these, so there isn't any real overhead after the system calls necessary to verify that we've got a duplicate. If this is too much overhead, don't list other dynamic libraries when building (cc/CC -G) dynamic libraries. However, I don't recall anyone ever complaining about the speed of dlopen() -- not that that means there isn't a problem for some applications. > So I'm wondering how UnixWare 7.x.x deals with this aspect? > I guess it'd be helpful to know how it relates it OSR 5.0.x, too. > > This will help SCO's OS's get well supported by libtool and hopefully, > some better software for us all. OpenServer and UnixWare share the same behavior here. The basics of dynamic library dependencies and the like are common across many UNIX systems and are found in the Generic Application Binary Interface specification. There is an up-to-date version of the key portions of this available on SCO's web site: http://www.sco.com/developer/gabi -- Dave Prosserdfp at sco dot com SCO, Murray Hill, NJ That's all. Matthew ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
-F parameter appears not to be passed in OS X
Using libtool 1.5.18 on OS X 10.4:
% libtool --mode=link g++ -module -o foo.la -rpath /usr/local/lib -F/foo
-framework frame
Runs:
g++ ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o
.libs/foo.0.0.0.so -bundle -framework frame
But would expect it to be something like:
g++ ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o
.libs/foo.0.0.0.so -bundle -F/foo -framework frame
The -F parameter (to give an extra path to the frameworks) seems to be
thrown away. Am I doing something wrong or is there a problem with libtool?
Thanks!
Matthew
--
Dr. Matthew Landauer
Visual Appliance Limited
www.visualappliance.com
+61 (0)8 8223 1268
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: -F parameter appears not to be passed in OS X
Thanks for that! That's a really good workaround. I'm productive again! :-)
Maybe I'm misunderstanding things but shouldn't libtool understand "-F"?
It knows how to interpret -framework and -F goes with that as much as -L
goes along with -l for normal linking.
Matthew
On Tue, 2 Aug 2005, Matthew Landauer wrote:
Using libtool 1.5.18 on OS X 10.4:
% libtool --mode=link g++ -module -o foo.la -rpath /usr/local/lib
-F/foo -framework frame
Runs:
g++ ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o
.libs/foo.0.0.0.so -bundle -framework frame
But would expect it to be something like:
g++ ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o
.libs/foo.0.0.0.so -bundle -F/foo -framework frame
Try using
-Wc,-F/foo -Wl,-F/foo
rather than just
-F/foo
Libtool needs to parse the command line, and it only knows about
common compiler/linker command options. The -Wc/-Wl approach allows
the user to be explicit about the options which should be passed to
the compiler or linker.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED],
http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
Dr. Matthew Landauer
Visual Appliance Limited
www.visualappliance.com
+61 (0)8 8223 1268
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: -F parameter appears not to be passed in OS X
It's for linking against the SDK for Apple's Shake (2d compositing
package) which by default puts its frameworks in
/Applications/Shake/sdk/Frameworks (for Shake version 4) or
/Applications/Shake3.50/sdk/Frameworks (for Shake version 3.5).
Matthew
Matthew Landauer wrote:
Thanks for that! That's a really good workaround. I'm productive
again! :-)
Maybe I'm misunderstanding things but shouldn't libtool understand
"-F"? It knows how to interpret -framework and -F goes with that as
much as -L goes along with -l for normal linking.
Most people put their frameworks in
{/System,/Network,,~}/Library/Frameworks, where they are in the
default search path. People using libtool don't tend to have
uninstalled frameworks (the major use for -F, afaik) during build.
Why do you need -F, do many people actually need it? I have never seen
a request for this before.
Peter
--
Dr. Matthew Landauer
Visual Appliance Limited
www.visualappliance.com
+61 (0)8 8223 1268
___
http://lists.gnu.org/mailman/listinfo/libtool
Cross compiling for win32 confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm working on a couple libraries that have been successfully compiling via a autoconf/automake tool chain for quite some time. It also compiles successfully under windows with MSVC, but now I'm trying to get it to cross compile from linux to win32. ./configure appears to run fine, object compilation seems to be good too, but linking fails. libtool: link: warning: undefined symbols not allowed in i586-pc-mingw32msvc shared libraries After looking around a bit it appears that malloc is not being found, but it never explicity says it. As such, I'm not really sure what symbols aren't there, and the --debug option produces more data than I know what to do with. Any help on how to track down my actual problem would be greatly appreciated. ~ Matthew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEGbd7LrcoBjlTBf0RAi67AJ9l8Ch1xitENcFicFsQC9TRHPNndwCeIje4 qNAqM9mODdnNC2btOmx9Xyk= =DzUU -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Shared + Static Linking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have seven libraries that depend on a few very common *nix libraries, so when it comes to win32 cross-compile + deployment it gets a little annoying. So I'm wondering if I can link in a win32 .lib archive file into my shared object via automake/libtool. If this idea isn't completely off base, a few pointers would be greatly appreciated. ~ Matthew P.S. Thanks Ralf & Bob for the cross-compile help -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEGuG0LrcoBjlTBf0RArVAAJsEg6ReO+67v0esfEy4OJJ2huJz2ACePjz+ XdLmioaXyjs7SqUpeQeQjqA= =EnKB -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
should libtool check for the correct version of find?
Hi libtool developers and users, libtool appears to depend on Unix find. Under Cygwin, an incorrect path can cause the Windows FIND to be used instead. To the untrained eye, (that is, me two days ago) it's not obvious from the output of configure and libtool that this has happened. The only warning I got was this: FIND: Parameter format not correct buried in the make output. The make does not actually fail until about a page later in the transcript when a link fails with a series of "undefined reference" errors. My suggestion is that libtool should get configure to check for the correct version of find (i.e. Unix find not WINDOWS find) as part of checking the general environment. I feel that configure's job is to check that all the correct tools are in place to do a build, so if libtool is used, then configure/libtool should check which find is being run. I know that the Cygwin path order is a FAQ: http://www.cygwin.com/faq/faq_4.html#SEC42 however in my case all the other standard Unix tools seemed to be working OK. Although Cygwin sets up the correct PATH by default in /etc/profile, if you login remotely this can be bypassed. Unfortunately I do not have time to contribute a patch. But I thought you might be interested to hear of this case. I think it might save some other poor soul from the same painstaking search I just made. Cheers, Matthew. -- Matthew Arnison Research Engineer Canon Information Systems Research Australia ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: should libtool check for the correct version of find?
On Sunday 28 September 2003 10:41 pm, Earnie Boyd wrote: > Matthew Arnison wrote: > > My suggestion is that libtool should get configure to check for the > > correct version of find (i.e. Unix find not WINDOWS find) as part of > > checking the general environment. I feel that configure's job is to > > check that all the correct tools are in place to do a build, so if > > libtool is used, then configure/libtool should check which find is > > being run. > > Let's see, I've been involved with Cygwin for about five years and not > reading the Cygwin FAQ and other documentation before starting is the > biggest error from Cygwin newbies I've found. This isn't something > libtool needs to concern itself with. I read the documentation. However, the build was working with a local login, and failing with a certain kind of remote login. In addition, other Unix builds (which presumably did not depend on find) *were* working remotely. To diagnose the problem, I had a lengthy build log with several errors in it and two main suspects: Cygwin line endings and the environment variables. Cygwin also has idiosyncracies (inherited from Windows) with switching users in batched jobs and in mounting network drives, which was relevant for me as I was trying to get a nightly build working. If configure had reported on the useless FIND, I would have been able to eliminate all the other suspects straight away. > Then you've not setup Cygwin appropriately for this. Probably something > else that's in the FAQ. Remote batched execution under Cygwin is not something I've found any official Cygwin docs for. I am using the default setup. Things work fine locally. But with a fairly standard install it seems Cygwin sshd bypasses the normal PATH setup when a user runs remote commands via ssh. This poorly documented selective sourcing of startup scripts under Unix is something that I think could really be improved on by the distributions, but that's another story. > Since, just as yourself, others will fail to read, others will still > have pains. I am not suggesting that libtool should bring up the user's web browser and point them at the Cygwin FAQ. I am simply suggesting that if libtool dependson a certain version of find, then configure+libtool should check for that version of find, just as it checks all the other Unix tools it depends on before attempting to use them in a build. If configure checked for a usable version of find, it would have given me a simple error and stopped the build before it started. To my mind that's exactly why configure exists: to make it easier to for software to compile on all the diverse flavours of Unix by checking carefully everything that the software build depends upon. The best argument I can see against this is that I had remote logins under Cygwin setup incorrectly. But think of the case on a Sun machine where a Unix build depends on GNU make instead of Solaris make. Remote login might switch the path and put the wrong one first, but for this case configure would detect the problem immediately and alert the user. It would be considered a serious error for the build to be allowed to continue and thereby allow Solaris make to spew mysterious errors. Or think about what would happen if a software build was working fine on SGI IRIX, until SGI decided to change the default version of one of the build tools in a way that it broke the build. The right thing to do would be to add a test in the configure script for any software that depended on that build tool. >From my point of view there is little difference between the above Solaris and SGI cases, and what happened to me on Cygwin . Now I think about it, the libtool response to the Windows FIND was also somewhat surprising. When FIND failed with "Parameter format not correct", libtool carried on regardless and built a library with most of the object files missing. The error that finally stopped the build was when gcc tried to link against that library. However, I can understand that Windows FIND probably doesn't return the normal Unix-like exit codes which libtool can check. In my mind this makes an even stronger argument for checking for find in the configure script. The sooner a bug is caught, the less havoc it can cause. Once again, I apologise for not being able to offer a patch at this stage. However, I offer this bug report in the hope that it is useful nonetheless. Cheers, Matthew. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Linking order
Is this a bug or a feature: I am working on a project that should compile both globally--with prefix unset so install goes to /usr/local/ and with prefix set to an arbitrary directory. When the program links, even if I define an -L or an rpath, it looks to /usr/local/lib for libraries even though I have prefix set to something else and libraries that I am making going there. for instance, if I have: /usr/local/lib/libsomething.so.1 and /home/zeitsm/lib/libsomething.so.0 I get the output of ldd as /home/zeitsm/lib/libsomething.so.0 . . . /usr/local/lib/libsomething.so.1 even when doing the local build...i.e. going into the .lib directory in the source, libtool links the .la file and the /usr/local/lib file? when I changed the revlevel of my library to: /home/zeitsm/lib/libsomething.so.3, it links only against that(or at least ldd reports such), but when I run it, it still looks to /usr/local/lib/libsomething.so.2? I can tell this by moving /usr/local/lib/libsomething.so.2 somewhere else, and the executable complains about /usr/local/lib/libsomething.so.2 missing--even though ldd does not list it as having a path. Is this a feature or a bug? I am using libtool 1.5.2 and slackware 9.1 on a p4 platform Matthew Zeits ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Creating dynamic libraries
Hello, I've been trolling around google and the mailing list archives and can't find the answers I'm looking for, so hopefully this is the right place to turn... I'm trying to extend a package by allowing it to crease shared dynamic libraries which I plan to link against in a perl package. I've found a way to create what I want, but upon reading a bit I've found it's probably not portable beyond linux, so I'm trying to determine the "right way" to do it. Everything I've read indicates I should use libtool, but I'm having trouble determining exactly how to get libtool to make shared dynamic libraries. I've currently modified this package's existing Makefile.in to have the following line: libhmmer.so: $(OBJS) $(CC) -shared -Wl,-soname,libhmmer.so -o libhmmer.so $(OBJS) >From what I understand .so is very linux-centric. How would I create something more portable? Or even configure things so a dynamic library is only created when supported by the OS? This package already has the following section: libhmmer.a: $(OBJS) $(AR) libhmmer.a $(OBJS) $(RANLIB) libhmmer.a chmod 644 libhmmer.a Which again, I'm unsure of the portability of this. Any advice would be welcome. Thanks. -- Matthew Laird SysAdmin/Web Developer, Brinkman Laboratory, MBB Dept. Simon Fraser University ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Libtool adds -lc when it shouldn't
ssues one to ld. In the configure I force the check for needing lc to fail by adding the following line to the config cache: archive_cmds_need_lc=no Which is then properly propogated into the libtool script generated in the directory. I have tried tracing through the generated libtool script, but I cannot see anywhere where -lc is explicitly added, except for one place which is not executed as archive_cmds_need_lc is no, not yes as is needed for the if statement (do a search for -lc and you will see what I mean) Is there something basic I am missing here? Is there another command needed to overide this option? Please let me know, Matthew Warton [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
