From: Pierre O. <os...@ce...> - 2005-12-14 08:01:26
|
I'm a bit new to cross-compiling with mingw, so bare with me if my questions are overly stupid. :) I'm working on porting polypaudio to the Windows platform. We want to be able to build this on Linux hosts, so the ambition is to make it compile and link using mingw. The main polypaudio library is supposed to become a DLL. When trying to link it though, libtool complains loudly about only finding a static version of libm. I'm at a loss what should be done to remedy this. I don't really understand why libtool has a problem with this. It should be possible to link a library statically, just like any other object file. -- Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Michael G. <mg...@te...> - 2005-12-14 08:58:40
|
> The main polypaudio library is supposed to become a DLL. When trying to=20 > link it though, libtool complains loudly about only finding a static=20 > version of libm. I'm at a loss what should be done to remedy this. I'm not sure I understand what you do but it seems you explicitly invoke libtool. Why ? Or phrased differently: Why don't you just invoke gcc/g++ with the appropriate options and let it do all the dirty details ? If the above is beside the point it might be helpful if you post the exact commands you are executing. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Pierre O. <os...@ce...> - 2005-12-14 09:09:44
|
Michael Gerdau wrote: >>The main polypaudio library is supposed to become a DLL. When trying to >>link it though, libtool complains loudly about only finding a static >>version of libm. I'm at a loss what should be done to remedy this. > > > I'm not sure I understand what you do but it seems you explicitly > invoke libtool. Why ? > > Or phrased differently: > Why don't you just invoke gcc/g++ with the appropriate options > and let it do all the dirty details ? > It's autotooled so libtool handles all the library stuff. The point is adding mingw support to the current structure and not creating an entire new build system just for one platform. > > If the above is beside the point it might be helpful if you post > the exact commands you are executing. > automake & co generates the makefile, so there's few additions on my part. But here is what is finally executed: /bin/sh ../libtool --mode=link i386-mingw32msvc-gcc -D_GNU_SOURCE -I/home/ossman/polypaudio -I/usr/local/cross-w32//include -I/usr/local/cross-w32//include -DDLSEARCHPATH=\"/usr/local/cross-w32//lib/polypaudio-0.8\" -DDEFAULT_CONFIG_DIR=\"/usr/local/cross-w32//etc/polypaudio\" -DPOLYPAUDIO_BINARY=\"/usr/local/cross-w32//bin/polypaudio\" '-DDEBUG_TRAP=__asm__("int $3")' -g -O2 -pipe -W -Wall -pedantic -std=gnu9x -Wno-unused-parameter -no-undefined -o libpolyp-simple-0.8.la -rpath /usr/local/cross-w32//lib -version-info 0:0:0 libpolyp_simple_0.8_la-polyplib-simple.lo libpolyp-0.8.la libpolyp-mainloop-0.8.la -lm Which gives me: *** Warning: linker path does not have real file for library -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libm and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/local/cross-w32/lib/gcc-lib/i386-mingw32msvc/3.2/../../../../i386-mingw32msvc/lib//libm.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. If I bastardise libtool and remove the check for the above, it links fine. I haven't gotten to the point of linking the library to something functional yet so I don't know if it produces a correct dll. -- Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Michael G. <mg...@te...> - 2005-12-14 18:47:47
|
> It's autotooled so libtool handles all the library stuff. The point is=20 > adding mingw support to the current structure and not creating an entire= =20 > new build system just for one platform. Ok. > automake & co generates the makefile, so there's few additions on my=20 > part. But here is what is finally executed: >=20 > /bin/sh ../libtool --mode=3Dlink i386-mingw32msvc-gcc -D_GNU_SOURCE=20 > -I/home/ossman/polypaudio -I/usr/local/cross-w32//include=20 > -I/usr/local/cross-w32//include=20 > -DDLSEARCHPATH=3D\"/usr/local/cross-w32//lib/polypaudio-0.8\"=20 > -DDEFAULT_CONFIG_DIR=3D\"/usr/local/cross-w32//etc/polypaudio\"=20 > -DPOLYPAUDIO_BINARY=3D\"/usr/local/cross-w32//bin/polypaudio\"=20 > '-DDEBUG_TRAP=3D__asm__("int $3")' -g -O2 -pipe -W -Wall -pedantic=20 > -std=3Dgnu9x -Wno-unused-parameter -no-undefined -o=20 > libpolyp-simple-0.8.la -rpath /usr/local/cross-w32//lib -version-info=20 > 0:0:0 libpolyp_simple_0.8_la-polyplib-simple.lo libpolyp-0.8.la=20 > libpolyp-mainloop-0.8.la -lm >=20 > Which gives me: >=20 > *** Warning: linker path does not have real file for library -lm. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because I did check the linker path looking for a file starting > *** with libm and none of the candidates passed a file format test > *** using a file magic. Last file checked:=20 > /usr/local/cross-w32/lib/gcc-lib/i386-mingw32msvc/3.2/../../../../i386-mi= ngw32msvc/lib//libm.a > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. I'm not sure wether it is of any importance but why are there these doubled '//' in your paths ? And could it be that this prevents libtool from finding your libm.a which I presume can be found under /usr/local/cross-w32/i386-mingw32msvc/lib/libm.a Just guessing. > If I bastardise libtool and remove the check for the above, it links=20 > fine. I haven't gotten to the point of linking the library to something=20 > functional yet so I don't know if it produces a correct dll. If the above guesswork is correct then it should work fine. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Pierre O. <os...@ce...> - 2005-12-15 09:03:56
|
Michael Gerdau wrote: >> >>*** Warning: linker path does not have real file for library -lm. >>*** I have the capability to make that library automatically link in when >>*** you link to this library. But I can only do this if you have a >>*** shared version of the library, which you do not appear to have >>*** because I did check the linker path looking for a file starting >>*** with libm and none of the candidates passed a file format test >>*** using a file magic. Last file checked: >>/usr/local/cross-w32/lib/gcc-lib/i386-mingw32msvc/3.2/../../../../i386-mingw32msvc/lib//libm.a >>*** The inter-library dependencies that have been dropped here will be >>*** automatically added whenever a program is linked with this library >>*** or is declared to -dlopen it. > > > I'm not sure wether it is of any importance but why are there > these doubled '//' in your paths ? > It gets those from the compiler so gcc's build scripts are to blame there. > And could it be that this prevents libtool from finding your > libm.a which I presume can be found under > /usr/local/cross-w32/i386-mingw32msvc/lib/libm.a > > Just guessing. > It finds it. It just doesn't like it. libtool expects a WIN32 PE file, libm.a is a archive. That's why the "fix" of removing this check works. The problem seems to be that libtool doesn't like linking static libraries to a dynamic one. I'd say this is a bit of a misfeature so the question is how to make libtool play nice. -- Rgds Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Ralf W. <Ral...@gm...> - 2005-12-14 19:29:45
|
Hi Pierre, * Pierre Ossman wrote on Wed, Dec 14, 2005 at 10:09:35AM CET: > Michael Gerdau wrote: > >>The main polypaudio library is supposed to become a DLL. When trying to > >>link it though, libtool complains loudly about only finding a static > >>version of libm. I'm at a loss what should be done to remedy this. > automake & co generates the makefile, so there's few additions on my > part. But here is what is finally executed: > > /bin/sh ../libtool --mode=link i386-mingw32msvc-gcc -D_GNU_SOURCE > -I/home/ossman/polypaudio -I/usr/local/cross-w32//include > -I/usr/local/cross-w32//include > -DDLSEARCHPATH=\"/usr/local/cross-w32//lib/polypaudio-0.8\" > -DDEFAULT_CONFIG_DIR=\"/usr/local/cross-w32//etc/polypaudio\" > -DPOLYPAUDIO_BINARY=\"/usr/local/cross-w32//bin/polypaudio\" > '-DDEBUG_TRAP=__asm__("int $3")' -g -O2 -pipe -W -Wall -pedantic > -std=gnu9x -Wno-unused-parameter -no-undefined -o > libpolyp-simple-0.8.la -rpath /usr/local/cross-w32//lib -version-info > 0:0:0 libpolyp_simple_0.8_la-polyplib-simple.lo libpolyp-0.8.la > libpolyp-mainloop-0.8.la -lm > > Which gives me: > > *** Warning: linker path does not have real file for library -lm. > If I bastardise libtool and remove the check for the above, it links > fine. I haven't gotten to the point of linking the library to something > functional yet so I don't know if it produces a correct dll. I believe I fixed that in Libtool branch-1-5 after 1.5.20 (and CVS HEAD). So it will be in 1.5.22, which I hope we can release very soon. But thanks for reporting this, reminds me to test that this actually works now. Cheers, Ralf |
From: Pierre O. <os...@ce...> - 2005-12-15 09:03:58
|
Ralf Wildenhues wrote: >>If I bastardise libtool and remove the check for the above, it links >>fine. I haven't gotten to the point of linking the library to something >>functional yet so I don't know if it produces a correct dll. > > > I believe I fixed that in Libtool branch-1-5 after 1.5.20 (and CVS > HEAD). So it will be in 1.5.22, which I hope we can release very soon. > > But thanks for reporting this, reminds me to test that this actually > works now. > Do you have a patch I can try out? -- Rgds Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Ralf W. <Ral...@gm...> - 2005-12-15 17:18:37
|
Hi Pierre, * Pierre Ossman wrote on Thu, Dec 15, 2005 at 10:03:51AM CET: > Ralf Wildenhues wrote: > >>If I bastardise libtool and remove the check for the above, it links > >>fine. I haven't gotten to the point of linking the library to something > >>functional yet so I don't know if it produces a correct dll. > > > >I believe I fixed that in Libtool branch-1-5 after 1.5.20 (and CVS > >HEAD). So it will be in 1.5.22, which I hope we can release very soon. > Do you have a patch I can try out? See http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00236.html It's specific to libm. Cheers, Ralf |
From: Pierre O. <os...@ce...> - 2005-12-16 07:08:52
|
Ralf Wildenhues wrote: > Hi Pierre, > > * Pierre Ossman wrote on Thu, Dec 15, 2005 at 10:03:51AM CET: > >>Ralf Wildenhues wrote: >> >>>>If I bastardise libtool and remove the check for the above, it links >>>>fine. I haven't gotten to the point of linking the library to something >>>>functional yet so I don't know if it produces a correct dll. >>> >>>I believe I fixed that in Libtool branch-1-5 after 1.5.20 (and CVS >>>HEAD). So it will be in 1.5.22, which I hope we can release very soon. > > >>Do you have a patch I can try out? > > > See > http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00236.html > It's specific to libm. > Ok. I get the same kind of issue on all Windows libs aswell, so there must be something more going on here. Rgds Pierre |
From: Ralf W. <Ral...@gm...> - 2005-12-16 18:23:12
|
* Pierre Ossman wrote on Fri, Dec 16, 2005 at 08:08:33AM CET: > Ralf Wildenhues wrote: > > > >See > >http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00236.html > >It's specific to libm. > > Ok. I get the same kind of issue on all Windows libs aswell, so there > must be something more going on here. If you mean: for other libraries, it does not work with libtool to link a dll against a static library. Then yes, libtool currently explicitly disallows that (except for import libraries), I believe. There has been quite some discussion about this on the various libtool/mingw/cygwin lists about this; if you feel you'd like to convince the crowd to change this (no need to convince *me*, I'm very indifferent to the question), feel free (after reading up on it). Tell me if you need pointers. Cheers, Ralf |
From: Pierre O. <os...@ce...> - 2005-12-19 08:23:39
|
Ralf Wildenhues wrote: > * Pierre Ossman wrote on Fri, Dec 16, 2005 at 08:08:33AM CET: > >>Ralf Wildenhues wrote: >> >>>See >>>http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00236.html >>>It's specific to libm. >> >>Ok. I get the same kind of issue on all Windows libs aswell, so there >>must be something more going on here. > > > If you mean: for other libraries, it does not work with libtool to link > a dll against a static library. > > Then yes, libtool currently explicitly disallows that (except for import > libraries), I believe. There has been quite some discussion about this > on the various libtool/mingw/cygwin lists about this; if you feel you'd > like to convince the crowd to change this (no need to convince *me*, I'm > very indifferent to the question), feel free (after reading up on it). > Tell me if you need pointers. > These are the libraries that are included with mingw. So I would guess they are import libraries for Microsoft's DLL:s. Examples are the winsock libraries (libwsock32.a, libws2_32.a). I'm hoping that crowd doesn't have strong objections about DLL:s using things outside libc. ;) Rgds Pierre |
From: Ralf W. <Ral...@gm...> - 2005-12-19 09:56:24
|
Hi Pierre, * Pierre Ossman wrote on Mon, Dec 19, 2005 at 09:23:25AM CET: > Ralf Wildenhues wrote: > > > >If you mean: for other libraries, it does not work with libtool to link > >a dll against a static library. > > > >Then yes, libtool currently explicitly disallows that (except for import > >libraries), I believe. There has been quite some discussion about this > >on the various libtool/mingw/cygwin lists about this; if you feel you'd > >like to convince the crowd to change this (no need to convince *me*, I'm > >very indifferent to the question), feel free (after reading up on it). > >Tell me if you need pointers. > > These are the libraries that are included with mingw. So I would guess > they are import libraries for Microsoft's DLL:s. Examples are the > winsock libraries (libwsock32.a, libws2_32.a). > > I'm hoping that crowd doesn't have strong objections about DLL:s using > things outside libc. ;) Misunderstanding. libtool aims to provide portable functionality for creating shared libraries. Now, on several gazillion systems, it is not possible to create a shared library that links against a static library. Exceptions are GNU/Linux on x86, most w32 systems (I don't know about w32/x86_64?), AIX, and probably a couple of others. Thus, the current behavior is to basically not allow to create a shared library that depends on a static library, because that is not portable functionality. For w32 systems, an exception has been made to accomodate for import libraries, because essentially they are used to link against shared libs. If you want libtool to create shared libs that link against libwsock32.a (it not being an import library), you have to make the point that it should allow the exception on w32. Or, FWIW, on cross-compilations to w32, because frankly you won't see the issue with a native build, as those libraries _will_ be available in shared form. Again, note I am merely pointing out the current state of the discussion rather than my personal opinion about this. And again, this discussion needs people from the other w32 systems involved (cygwin, for example), so it would better be done on the libtool list. What you expect quite naturally to work, is an unusual situation for other people; you need to keep in mind that other people do not have your view or expectation of how "things are supposed to work". Cheers, Ralf |
From: Pierre O. <os...@ce...> - 2005-12-19 10:19:19
|
Ralf Wildenhues wrote: > > If you want libtool to create shared libs that link against libwsock32.a > (it not being an import library), you have to make the point that it > should allow the exception on w32. Or, FWIW, on cross-compilations to > w32, because frankly you won't see the issue with a native build, as > those libraries _will_ be available in shared form. libwsock32.a should be an import library. Or does mingw contain complete implementations of the windows libraries? :) I don't need to be able to link static stuff to a dll. I just want to be able to cross-compile a dll that uses the standard Win32 API. -- Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Ralf W. <Ral...@gm...> - 2005-12-19 10:39:48
|
* Pierre Ossman wrote on Mon, Dec 19, 2005 at 11:19:04AM CET: > Ralf Wildenhues wrote: > > > >If you want libtool to create shared libs that link against libwsock32.a > >(it not being an import library), you have to make the point that it > >should allow the exception on w32. Or, FWIW, on cross-compilations to > >w32, because frankly you won't see the issue with a native build, as > >those libraries _will_ be available in shared form. > > libwsock32.a should be an import library. Or does mingw contain complete > implementations of the windows libraries? :) Frankly, I don't know. > I don't need to be able to link static stuff to a dll. I just want to be > able to cross-compile a dll that uses the standard Win32 API. OK. Then I need to know exactly how to reproduce your problem. Which system are you on (if GNU/Linux: which distribution), how exactly did you create your cross tool chain (I'm willing to rebuild it if your instructions are precise enough), and how can I reproduce the link failure then? Alternatively, as a first approximation you could send me (off-list!) both the libtool script involved and one of libraries, eg. libwsock32.a. Or extract func_win32_libid from the libtool script, set $OBJDUMP, $EGREP, $NM, and $SED as at the beginning of the libtool script, and evaluate it on libwsock32.a. Post results, including a shell trace (set -x). Cheers, Ralf |
From: Pierre O. <os...@ce...> - 2005-12-19 11:44:26
|
Ralf Wildenhues wrote: > * Pierre Ossman wrote on Mon, Dec 19, 2005 at 11:19:04AM CET: > >>I don't need to be able to link static stuff to a dll. I just want to be >>able to cross-compile a dll that uses the standard Win32 API. > > > OK. Then I need to know exactly how to reproduce your problem. > > Which system are you on (if GNU/Linux: which distribution), how exactly > did you create your cross tool chain (I'm willing to rebuild it if your > instructions are precise enough), and how can I reproduce the link > failure then? > This is a Red Hat 7.3 system (aged like a fine wine ;)). The build environment is set up from the mingw sources and should not have any special hacks. How it was set up isn't fully documented so there will be some research to figure that out. The result, at least, is that everything is located under /usr/local/cross-w32. Should be just gcc, binutils and mingw (import libs and headers) there. > > Or extract func_win32_libid from the libtool script, set $OBJDUMP, > $EGREP, $NM, and $SED as at the beginning of the libtool script, and > evaluate it on libwsock32.a. Post results, including a shell trace > (set -x). > (crossenv-w32 is just a script that sets the paths to the cross-compilation environment) [ossman@gorgonzola]$ crossenv-w32 ./libtest.sh /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a + func_win32_libid /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a + win32_libid_type=unknown ++ file -L /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a + win32_fileres=/usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a: current ar archive + eval i386-mingw32msvc-objdump -f /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a ++ i386-mingw32msvc-objdump -f /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a + sed -e 10q + egrep -e 'file format pe-i386(.*architecture: i386)?' ./libtest.sh: line -11: 30080 Broken pipe i386-mingw32msvc-objdump -f /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a ++ eval i386-mingw32msvc-nm -f posix -A /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a +++ i386-mingw32msvc-nm -f posix -A /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a ++ sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}' + win32_nmres=import + test Ximport = Ximport + win32_libid_type=x86 archive import + echo x86 archive import x86 archive import -- Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Ralf W. <Ral...@gm...> - 2005-12-19 12:32:26
|
Hi Pierre, * Pierre Ossman wrote on Mon, Dec 19, 2005 at 12:44:12PM CET: > Ralf Wildenhues wrote: > > >Which system are you on (if GNU/Linux: which distribution), how exactly > >did you create your cross tool chain (I'm willing to rebuild it if your > >instructions are precise enough), and how can I reproduce the link > >failure then? > > This is a Red Hat 7.3 system (aged like a fine wine ;)). Ouch. ;-) (it's fine; I remember how well that one worked at its time). > The build > environment is set up from the mingw sources and should not have any > special hacks. How it was set up isn't fully documented so there will be > some research to figure that out. OK, thanks. > >Or extract func_win32_libid from the libtool script, set $OBJDUMP, > >$EGREP, $NM, and $SED as at the beginning of the libtool script, and > >evaluate it on libwsock32.a. Post results, including a shell trace > >(set -x). > > (crossenv-w32 is just a script that sets the paths to the > cross-compilation environment) > > [ossman@gorgonzola]$ crossenv-w32 ./libtest.sh > /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a > > + func_win32_libid /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a *snip* > x86 archive import OK, thanks for doing this. Now I need the output of i386-mingw32msvc-objdump -f \ /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a and I should be able to produce a patch then. Cheers, Ralf |
From: Pierre O. <os...@ce...> - 2005-12-19 12:40:38
|
Ralf Wildenhues wrote: > > OK, thanks for doing this. Now I need the output of > i386-mingw32msvc-objdump -f \ > /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a > > and I should be able to produce a patch then. > It should be me thanking you for sorting this mess out. libtool is a bit too much voodoo to me. :) $ crossenv-w32 i386-mingw32msvc-objdump -f \ /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a In archive /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a: ducft.o: file format pe-i386 architecture: i386, flags 0x00000038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfh.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00072.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00071.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00070.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00069.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00068.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00067.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00066.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00065.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00064.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00063.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00062.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00061.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00060.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00059.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00058.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00057.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00056.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00055.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00054.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00053.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00052.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00051.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00050.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00049.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00048.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00047.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00046.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00045.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00044.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00043.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00042.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00041.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00040.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00039.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00038.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00037.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00036.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00035.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00034.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00033.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00032.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00031.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00030.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00029.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00028.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00027.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00026.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00025.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00024.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00023.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00022.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00021.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00020.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00019.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00018.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00017.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00016.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00015.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00014.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00013.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00012.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00011.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00010.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00009.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00008.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00007.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00006.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00005.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00004.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00003.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00002.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00001.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 ducfs00000.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 -- Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Ralf W. <Ral...@gm...> - 2005-12-19 13:01:26
|
[ getting libtool-patches into play; this thread is archived at http://sourceforge.net/mailarchive/forum.php?thread_id=9231830&forum_id=5119 ] * Pierre Ossman wrote on Mon, Dec 19, 2005 at 01:40:22PM CET: > Ralf Wildenhues wrote: > > > >OK, thanks for doing this. Now I need the output of > > i386-mingw32msvc-objdump -f \ > > /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a > > > >and I should be able to produce a patch then. > > It should be me thanking you for sorting this mess out. libtool is a bit > too much voodoo to me. :) I agree that libtool has a long learning curve (not really steep, because unfortunately it's hard to learn it quickly); I have not yet found good ways to improve upon that without major rewrites (and lots of documentation improvements to which I haven't found the time yet nor the way to motivate others to do it ;-). > $ crossenv-w32 i386-mingw32msvc-objdump -f \ > /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a > > In archive /usr/local/cross-w32/i386-mingw32msvc/lib/libwsock32.a: OK. Please try this patch. It's a bit simple-minded, but should be fairly safe. You need to regenerate your configure script (and maybe also aclocal.m4 and stuff) to pick up the libtool.m4 changes. Alternatively, just to try whether this works at all, you could edit the libtool script directly and change deplibs_check_method="file_magic ^x86 archive import|^x86 DLL" and file_magic_cmd="func_win32_libid" once for each tag (for C: at the beginning of the script; for C++ etc. at the very end). Question to libtool folks: OK to apply this patch? Cheers, Ralf * libtool.m4 (AC_DEPLIBS_CHECK_METHOD) [ mingw, pw32 ]: If `file' is present, use `func_win32_libid' rather than `objdump -f', to facilitate cross-compilation. Reported by Pierre Ossman <os...@ce...>. Index: libtool.m4 =================================================================== RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.145 diff -u -r1.314.2.145 libtool.m4 --- libtool.m4 18 Dec 2005 22:14:06 -0000 1.314.2.145 +++ libtool.m4 19 Dec 2005 12:47:58 -0000 @@ -2295,9 +2295,15 @@ mingw* | pw32*) # Base MSYS/MinGW do not provide the 'file' command needed by - # func_win32_libid shell function, so use a weaker test based on 'objdump'. - lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?' - lt_cv_file_magic_cmd='$OBJDUMP -f' + # func_win32_libid shell function, so use a weaker test based on 'objdump', + # unless we find 'file', for example because we are cross-compiling. + if ( file / ) >/dev/null 2>&1; then + lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' + lt_cv_file_magic_cmd='func_win32_libid' + else + lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?' + lt_cv_file_magic_cmd='$OBJDUMP -f' + fi ;; darwin* | rhapsody*) |
From: Pierre O. <os...@ce...> - 2005-12-19 14:09:46
|
Ralf Wildenhues wrote: > > OK. Please try this patch. It's a bit simple-minded, but should be > fairly safe. You need to regenerate your configure script (and maybe > also aclocal.m4 and stuff) to pick up the libtool.m4 changes. > Everything seems to link fine now. Thanks for all the help. :) -- Pierre Ossman Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com |
From: Ralf W. <Ral...@gm...> - 2005-12-21 17:45:17
|
[ adding subscribers-only mingw-users back -- they may have useful input on this ] Hi Bob, * Bob Friesenhahn wrote on Mon, Dec 19, 2005 at 06:46:21PM CET: > On Mon, 19 Dec 2005, Ralf Wildenhues wrote: > > > >Question to libtool folks: OK to apply this patch? > > There are other reasons not to find the 'file' command. For example, > it does not appear to be provided with the MSYS environment. But > objdump is provided with MinGW. That is why I had MinGW using objdump > while Cygwin uses file. Sure. > The patch assumes particular output from the 'file' command. It assumes that, for an ar archive, it will output something matching *ar\ archive* (in shell pattern notation). I believe that is fairly safe; I've even tested that now on some BSDs. Note func_win32_libid uses `$OBJDUMP -f' and `$NM -f posix -A ..' to determine whether it's an import library. Both of those tools have to be part of the cross-toolchain on non-mingw, so that should be safe as well. Besides, if my patch introduced brokenness for cross-compiles, that would already be broken for any cross-compile to cygwin anyway. > Since there is no standard 'file' command provided with MSYS/MinGW, is > this safe? OK, so the only remaining case really is MSYS/MinGW itself. Do we know of win32 installations that provide a `file' command that does not do what we expect? Note that not having `file' available would be fine here, but one that does something completely unrelated, for example, would hurt. Maybe we should limit use of func_win32_libid to the case where both `file' is available and $host != $build? > What if MinGW is used in a cross-development environment (e.g. some > *BSD environment) which uses a different 'file' program than expected? See above: that should be safe. Any more issues? Cheers, Ralf > > * libtool.m4 (AC_DEPLIBS_CHECK_METHOD) [ mingw, pw32 ]: > > If `file' is present, use `func_win32_libid' rather than > > `objdump -f', to facilitate cross-compilation. > > Reported by Pierre Ossman <os...@ce...>. |
From: Keith M. <kei...@to...> - 2005-12-22 18:08:30
|
Ralf Wildenhues wrote, quoting Bob Frieshahn: >> Since there is no standard 'file' command provided with MSYS/MinGW, >> is this safe? > > OK, so the only remaining case really is MSYS/MinGW itself. Do we > know of win32 installations that provide a `file' command that does > not do what we expect? Note that not having `file' available would > be fine here, but one that does something completely unrelated, for > example, would hurt. While it is true that MSYS/MinGW doesn't include a `file' command as standard, it is perfectly feasible to use a `foreign' implementation with MSYS; e.g. I have installed the GnuWin32 v4.16 implementation http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=18878 into my `/usr/local' MSYS tree. Not sure how robust it is; e.g. it misidentifies manpage sources as `MKS Spell hash (old format)', and its own manpage refers to incorrect locations for the `magic' files, but it does seem to identify executables, shell scripts, and `*.a' or `*.dll' libraries reasonably well. There may be a few gotchas, such as:-- * executable names need to be spelled out in full, including the EXEEXT; (file `which sh` says `no such file or directory', but file `which sh.exe` works as expected). * `*.o' files are identified as `80386 COFF executable, not stripped', rather than as relocatable (object) files; (file-3.37 on my Linux box does likewise, for i586-mingw32-gcc compiled objects). * may be some other weirdos I haven't encountered yet... Not suggesting that you should always expect `file' to be present, but some MSYS users may have it. Maybe, if it's needed to improve libtool support, we could consider adding it to a future msysDTK release, or provide it as a mingwPORT. Regards, Keith. |
From: Earnie B. <ea...@pr...> - 2005-12-22 21:43:41
|
Quoting Keith MARSHALL <kei...@to...>: > > Not suggesting that you should always expect `file' to be present, but > some MSYS users may have it. Maybe, if it's needed to improve libtool > support, we could consider adding it to a future msysDTK release, or > provide it as a mingwPORT. > Some fine user donated a shell script version of file and attached it to a bug report about this issue. I was planning to put it in a next release. It has been ages since a release has happened and at the moment it looks like it will be ages still. Kind Regards, Earnie Boyd For all your online shopping needs http://shop.siebunlimited.com. Register an account online and receive a 25% discount on your first purchase. |
From: Ralf W. <Ral...@gm...> - 2005-12-23 07:17:13
|
* Keith MARSHALL wrote on Thu, Dec 22, 2005 at 06:17:57PM CET: > Ralf Wildenhues wrote, quoting Bob Frieshahn: > > > > OK, so the only remaining case really is MSYS/MinGW itself. Do we > > know of win32 installations that provide a `file' command that does > > not do what we expect? > > While it is true that MSYS/MinGW doesn't include a `file' command as > standard, it is perfectly feasible to use a `foreign' implementation > with MSYS; e.g. I have installed the GnuWin32 v4.16 implementation > http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=18878 > into my `/usr/local' MSYS tree. Not sure how robust it is; e.g. it > misidentifies manpage sources as `MKS Spell hash (old format)', and > its own manpage refers to incorrect locations for the `magic' files, > but it does seem to identify executables, shell scripts, and `*.a' > or `*.dll' libraries reasonably well. Those are the important bits. Thanks for mentioning this, I'll try GnuWin32 for testing. > Not suggesting that you should always expect `file' to be present, but > some MSYS users may have it. Maybe, if it's needed to improve libtool > support, we could consider adding it to a future msysDTK release, or > provide it as a mingwPORT. Well, I've thought of rewriting func_win32_libid in a way that would not require `file' at all, rather than asking you to add it. Have to think about this a bit more, when I have more time. * Earnie Boyd wrote on Thu, Dec 22, 2005 at 10:45:37PM CET: > > Some fine user donated a shell script version of file and attached it > to a bug report about this issue. I was planning to put it in a next > release. It has been ages since a release has happened and at the > moment it looks like it will be ages still. While you're already considering adding tools to improve libtool support, may I kindly point to http://sourceforge.net/mailarchive/message.php?msg_id=13069136 which has not been addressed yet, as far as I can see. It would help us very much to convince to change the GCS, and it would enable a complexity reduction (and thus quite some speedup, esp. on mingw in some cases) for 'libtool --mode=link' with a large number of objects. Cheers, Ralf |
From: Keith M. <kei...@to...> - 2005-12-23 10:27:12
|
Ralf Wildenhues wrote: > While you're already considering adding tools to improve libtool > support, may I kindly point to > http://sourceforge.net/mailarchive/message.php?msg_id=13069136 which > has not been addressed yet, as far as I can see. It would help us > very much to convince to change the GCS, and it would enable a > complexity reduction (and thus quite some speedup, esp. on mingw in > some cases) for 'libtool --mode=link' with a large number of objects. Hi Ralf, If I interpret that correctly, you are specifically asking for `join' and `paste', from GNU coreutils; you would also like `fold' and `split', but we provide then already, so I guess you are just suggesting that they be mandated by GCS. Sure, we could consider distributing these, but don't hold your breath waiting. I tried to build a Win32 native GNU coreutils with MinGW quite recently, and the `make' failed miserably. Unless some kind soul provides a mingwPORT, and/or feeds the necessary patches back into the coreutils project, these are unlikely to be available any time soon. For now, you could try the GnuWin32 port -- I don't know how effective that might be. It is possible that better success could be achieved by building MSYS special implementations. In the past, I believe, that Earnie has been the principal, if not sole, maintainer of such releases; at present he is unable to devote time to this task. Since I do all my development work on GNU/Linux, cross-compiling for Win32 using i586-mingw32-gcc, I am not equipped to host the special compiler environment required to create MSYS special components, so I can't pursue this option myself; anyone else like to take up the challenge? Regards, Keith. P.S. Please forward this to `libtool-patches' at your discretion; my previous post was bounced, awaiting moderator approval, and I have no desire to subscribe personally to that list. available. |
From: Ralf W. <Ral...@gm...> - 2005-12-23 10:53:40
|
Hi Keith, * Keith MARSHALL wrote on Fri, Dec 23, 2005 at 11:17:08AM CET: > Ralf Wildenhues wrote: > > http://sourceforge.net/mailarchive/message.php?msg_id=13069136 which > > If I interpret that correctly, you are specifically asking for `join' > and `paste', from GNU coreutils; you would also like `fold' and `split', > but we provide then already, so I guess you are just suggesting that > they be mandated by GCS. Correct on all accounts. > Sure, we could consider distributing these, but don't hold your breath > waiting. I tried to build a Win32 native GNU coreutils with MinGW quite > recently, and the `make' failed miserably. Unless some kind soul provides > a mingwPORT, and/or feeds the necessary patches back into the coreutils > project, these are unlikely to be available any time soon. For now, > you could try the GnuWin32 port -- I don't know how effective that > might be. I don't think that would help for a GCS decision to mandate those tools: they should be readily available everywhere, otherwise they can't be considered necessary. Kind of a chicken-and-egg wrt. MSYS. :-) (By the way, I believe there are other systems we need to check for those tools, before actually proposing the GCS change.) But your statement still helps: I may just want to venture into porting those tools to MSYS when I have some time (sometime after 2.0 is done), unless beaten to, of course -- the prospect of maybe having them distributed when working is better than nothing. :-) > P.S. Please forward this to `libtool-patches' at your discretion; Done. > my previous post was bounced, awaiting moderator approval, I don't think it bounced, it merely needed first-time approval. I did that (and your post has shown up in the archives now); any further posts of yours should go through without approval. > and I have no desire to subscribe personally to that list. Fully understood. Sorry for the inconvenience -- spam has made this necessary. (For archive completeness only: it is also possible to subscribe and disable delivery, to forgo first-post moderation.) Cheers, Ralf |