4:08 a.m.
(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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
4:21 a.m.
New subject: mingw32-filesystem, mingw32-w32api, mingw32-runtime
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAklKJEIACgkQu9a1imXPdA/2iwCfQ/VPPbHM2TBkWlFFfZmTNoJi
wjEAnRYEnQnpuA1h/w6MnWl/3GfaFBJf
=PeAI
-----END PGP SIGNATURE-----
4:36 a.m.
New subject: mingw32-filesystem, mingw32-w32api, mingw32-runtime
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'
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
5:32 a.m.
New subject: mingw32-filesystem, mingw32-w32api, mingw32-runtime
-----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/...
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'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAklKNMAACgkQu9a1imXPdA99GgCfTfiikuCrK5CQs4r3qUYiazuM
ccsAnjg9mrzhrVEvp1x257m/7CrTyWE+
=K5mE
-----END PGP SIGNATURE-----
5:03 a.m.
New subject: mingw32-filesystem, mingw32-w32api, mingw32-runtime
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.
--
Levente "Si vis pacem para bellum!"
5608
days inactive
5608
days old
4 comments
3 participants
participants (3)
-
Farkas Levente -
Fridrich Strba -
Richard W.M. Jones