[Top][All Lists]

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

Re: MinGW DLLs and autoconf parsing

From: Jason Curl
Subject: Re: MinGW DLLs and autoconf parsing
Date: Wed, 16 Jul 2008 07:55:55 +0200
User-agent: Thunderbird (Windows/20080421)

Thanks Roumen, I've taken the same route as you've mentioned although it's hackish.

I'm hoping someone from the libtool developer community can comment.

Roumen Petrov wrote:
Jason Curl wrote:

Recently some info was posted about using resource files with Windows compilers. I'm trying to generate a reasonably simple Version resource and there's some information I'm not sure how I can extract from the build process. I'm using libtool-1.5.27a on MSYS-1.0.10 with MinGW-5.1.4.

Question 1:
One of the fields is "OriginalFilename". When the shared DLL is built, it is installed "libfoo-1.dll". I've created a "" file that autoconf generates for me, substituting information from the build process directly into this resource file.

However, how might I get the name of the library before it is built?

You may create library with name "libfoo.dll" if you call make with
Also you may set this flag in configure script for mingw host.
libtool don't preserve LIBRARY statement specified by def-file.

The string "-1" is suffix appended by libtool for cygwin/mingw host. The
number is equal to  "$current - $age" from version info.
Avoiding the version isn't a problem. I see that there's an advantage of using the version. But libtool generates a name, and is there an API to get this name? For different architectures, the naming scheme changes. Or do I need to install and parse the ".la" file to reliably get the name? Then I can't do this within '' where I do need the name (to generate a resource file from

And right now, I've just had to read the libtool source and figure it out. I expect breakages the next time I upgrade..

Question 2:
The second task is the versioning. There are two fields, both of the format:
FILEVERSION major,minor,revision,build

I need to substitute them based on the version information given to libtool during the linking phase.

How can I convert the string "1:0:0" to a major.minor.revision field? How does this work?

awk, sed , shell ?
- born shell sample:
IFS=:; set -- `echo a:b:c`; echo $1.$2.$3
Again, reading libtool it defines $major, $minor, $revision, but depending on the platform it changes. The string above is $current, $revision, $age, which is not the same thing. And I remember that it some versions of libtool for some particular platform it's really not obvious. Such a feature is not Windows specific. I have an API in most of my libraries to get the version information

Right now, I've just had to do:
$major = $current - $age  (c-a)
$minor = $age (a)
$rev = $revision (r)

Question 3:
As the libtool --tag=RC doesn't work for 1.5.27a (it complained about an unknown tag), I wrote the rule:

I guess that configure script is without macro AC_LIBTOOL_RC
Tried that already. I think this is probably a new feature for Libtool-2.x I ended up using the tag CC. I don't really know if using tag CC is really intended, or if there could be a breakage later with a different compiler toolset (other than gcc, or with a cross compiler)

$(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC --mode=compile $(RC) $(RCFLAGS) $< -o $@

where RC=windres and RCFLAGS is empty. It works, but is it safe? I don't know when MinGW will upgrade the autotools.

May be you need two rules : one to create %.lo file and one for object
file (%.o):
LTRCCOMPILE = $(LIBTOOL) --mode=compile --tag=RC $(RCCOMPILE)

    $(LTRCCOMPILE) -i "$<" -o "$@"

    $(RCCOMPILE) -i "$<" -o "$@"
.o files don't make sense for static libraries in this case, so I'm happy to see that for the static case it isn't even used and everything seems to work.

Thanks & Best Regards,


Thanks Roumen.

reply via email to

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