libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-users] libtool, dlls and -lm


From: Keith MARSHALL
Subject: Re: [Mingw-users] libtool, dlls and -lm
Date: Fri, 25 Aug 2006 13:40:29 +0100

Hi Ralf,

Ralf Wildenhues wrote, quoting me:
>> 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.
>
> I installed above `file' program, but for some reasons I haven't been
> able to analyze yet, I can't get it to work.

Strange; it worked OOTB for me.  I simply downloaded that package -- it
is a self extracting .exe installer -- ran it, and set the installation
path to `d:/msys/1.0/local'.

Do remember that MSYS maps *both* `/' and `/usr' to the root of your
MSYS installation -- `d:/msys/1.0' in my case -- and that this mapping
is unknown in non-MSYS aware applications; maybe you accidentally
included the `/usr' in the installation path?  (This would create a real
`d:/msys/1.0/usr/local' directory, in which the GnuWin32 files would be
installed, but they would then be occluded by the MSYS path mapping).

Another caveat, of which I'm sure you are aware, is not to use either
`d:/msys/1.0' itself, or `d:/msys/1.0/usr' as the installation path for
non MSYS packages -- unless you are running MSYS-1.0.11 -- as this will
violate the rule that non-MSYS binaries are not permitted in `/bin'.

> Could you do me a favour and post the literal output of `file', when
> applied to
> - an executable file (with the .exe applied),
> - a shell script,
> - a DLL,
> - a plain archive (*.a),
> - and an import library (usually named *.dll.a).

Does this gamut from a GNU-libiconv build tree fit the bill?

$ which file
/usr/local/bin/file.exe

$ file --version
D:\MSYS\1.0\local\bin\file.exe-4.16
magic file from D:/MSYS/1.0/local/share/file/magic

$ file bin/* lib/*
bin/iconv.exe;        MS Windows PE 32-bit Intel 80386 console executable 
not relocatable
bin/libcharset-1.dll; MS Windows PE 32-bit Intel 80386 console DLL
bin/libiconv-2.dll;   MS Windows PE 32-bit Intel 80386 console DLL
lib/charset.alias;    MKS Spell hash list (old format)
lib/libcharset.a;     current ar archive
lib/libcharset.dll.a; current ar archive
lib/libcharset.la;    MKS Spell hash list (old format)
lib/libiconv.a;       current ar archive
lib/libiconv.dll.a;   current ar archive
lib/libiconv.la;      MKS Spell hash list (old format)

$ file /bin/which
D:/MSYS/1.0/bin/which; Bourne shell script text executable

> Thank you very much in advance,

You're welcome.

Regards,
Keith.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]