(CC-ing to the mailing list with the original patches)
On Thu, Dec 18, 2008 at 12:52:19AM +0100, Fridrich Strba wrote:
I was doing some cloning of your Rawhide packages for my personal use and I discovered a bug in the _mingw32_make macro and also maybe some reasons why.
Setting the prefix to %{buildroot}%{prefix} is not seen as flawed now, but with more and more cross-built packages it will show that the libtool archive (*.la) files will give wrong prefix and result somehow also in linking errors.
I'm a bit confused by what the mistake is .. The *.la files we are generating now seem to have correct paths inside them. Can you point to an example where there is a problem?
I think that the reason is basically the w32api and mingwrt package where make install does not honour DESTDIR setting. Find attached two patches that will make that DESTDIR to be respected.
Also, I sent a proposed (IMHO better) mingw32 macros files. Note that the CLASSPATH variable is not useful for you people if you don't distribute the mingw32-gcc-java cross-compiler that I personally use for building of some java bindings of my private libraries. But the _mingw32_make and _mingw32_makeinstall macros could be considered I guess. I even make the mingw32-make symlink because several non-libtool applications cross-compile much better using mingw32-make which sets all the needed env variables.
Rich.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes, the gnu libiconv for instance will leave in the *.la file the directory in which the library will be installed and that will create a problem because libtool will not find it there.
Cheers
F.
Richard W.M. Jones wrote:
I'm a bit confused by what the mistake is .. The *.la files we are generating now seem to have correct paths inside them. Can you point to an example where there is a problem?
I think that the reason is basically the w32api and mingwrt package where make install does not honour DESTDIR setting. Find attached two patches that will make that DESTDIR to be respected.
Also, I sent a proposed (IMHO better) mingw32 macros files. Note that the CLASSPATH variable is not useful for you people if you don't distribute the mingw32-gcc-java cross-compiler that I personally use for building of some java bindings of my private libraries. But the _mingw32_make and _mingw32_makeinstall macros could be considered I guess. I even make the mingw32-make symlink because several non-libtool applications cross-compile much better using mingw32-make which sets all the needed env variables.
Rich.
On Thu, Dec 18, 2008 at 11:21:54AM +0100, Fridrich Strba wrote:
Yes, the gnu libiconv for instance will leave in the *.la file the directory in which the library will be installed and that will create a problem because libtool will not find it there.
I'm still not sure I understand. The libiconv.la file looks OK to me (see below). And we routinely link against libiconv.
Rich.
# libiconv.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.24 (1.1220.2.455 2007/06/24 02:13:29) # # Please DO NOT delete this file! # It is necessary for linking the library.
# The name that we can dlopen(3). dlname='../bin/libiconv-2.dll'
# Names of this library. library_names='libiconv.dll.a'
# The name of the static archive. old_library=''
# Libraries that this one depends upon. dependency_libs=''
# Version information for libiconv. current=6 age=4 revision=0
# Is this an already installed library? installed=yes
# Should we warn about portability when linking against -modules? shouldnotlink=no
# Files to dlopen/dlpreopen dlopen='' dlpreopen=''
# Directory that this library needs to be installed in: libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib'
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Richard W.M. Jones wrote:
I'm still not sure I understand. The libiconv.la file looks OK to me (see below). And we routinely link against libiconv.
Sure, because you don't use the _mingw32_make and _mingw32_makeinstall macro :)
http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/tip/ico...
If you used it, it would be a different story.
Now, there is another library that does not respect destdir, and it is libjpeg. I am attaching a patch to make it behave properly. It also produces win32 executables without exe prefix so they will not be considered by find-requires script. But that is easily fixed I guess by either moving them or by patching the makefile.cfg more. I did the former.
Cheers
Fridrich
# libiconv.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.24 (1.1220.2.455 2007/06/24 02:13:29) # # Please DO NOT delete this file! # It is necessary for linking the library.
# The name that we can dlopen(3). dlname='../bin/libiconv-2.dll'
# Names of this library. library_names='libiconv.dll.a'
# The name of the static archive. old_library=''
# Libraries that this one depends upon. dependency_libs=''
# Version information for libiconv. current=6 age=4 revision=0
# Is this an already installed library? installed=yes
# Should we warn about portability when linking against -modules? shouldnotlink=no
# Files to dlopen/dlpreopen dlopen='' dlpreopen=''
# Directory that this library needs to be installed in: libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib'
Richard W.M. Jones wrote:
I think that the reason is basically the w32api and mingwrt package where make install does not honour DESTDIR setting. Find attached two patches that will make that DESTDIR to be respected.
Also, I sent a proposed (IMHO better) mingw32 macros files. Note that the CLASSPATH variable is not useful for you people if you don't distribute the mingw32-gcc-java cross-compiler that I personally use for building of some java bindings of my private libraries. But the _mingw32_make and _mingw32_makeinstall macros could be considered I guess. I even make the mingw32-make symlink because several non-libtool applications cross-compile much better using mingw32-make which sets all the needed env variables.
it's a good question which is the better _mingw32_makeinstall your (which is recommended by the fedora packaging guide) the the old one which is similar to the original rpm's _makeinstall macro... actually i don't know i just would like to confirm to the base system.
-
Farkas Levente -
Fridrich Strba -
Richard W.M. Jones