. As such it works just fine as is.
Well, it /did/ -- until the new-libtool merge. Now there seem to be
build problems. So /something/ needs fixin'. g
Also,
libgcj has some local libltdl patches as well.
Then they should be submitted upstream -- if they are still necessary.
There have been a lot
On Wed, 06 Jun 2007 09:43:50 -0500, Peter O'Gorman said:
I'm lazy and would like to avoid work as much as possible, Gary has
already asked if you'd like a commit bit, I'm hoping you'll agree, then
all we'll need to do is say ok and you can commit your changes
yourself.
As long as somebody
entirely for $host=cygwin|mingw' was a
libtool-2.4 project. However, the current libtool-2.2 behavior was an
unreported (!) regression over 1.5.x, and the conversation last week
seemed to imply that it was important enough to try to fasttrack before
2.4...but that doesn't mean it will or can get
files for information.
Or is this purely for import libraries not created with libtool (and
people who throw away *.la files)?
The information (e.g. library to dlpreopen) is passed in $dlprefiles.
But, if that filename is .la:
func_mode_link():
...
dlfiles|dlprefiles)
if test
can instead create a
second file with the following content:
1 24 MOVEABLE PURE progname.manifest
and then
$ windres progname.rc progname.rc.o
$ ld -o new-progname.exe progname.exe progname.rc.o
$ mv new-progname.exe progname.exe
But that's overkill for the libtool cwrappers, and probably also
of
executable name. My gripe was that any file created by libtool will
overwrite the file generated by cl.exe and I think cl.exe will do
a better job of creating the manifest. My msvc patches then has code
to embed the manifest into the executable using mt (manifest tool),
but that is immaterial
* tests/cwrapper.at: Add new test 'cwrapper and installed shared
libraries.'
---
This patch was actually proposed by Roumen Petrov here:
http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html
He mentioned here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00222.html