* 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/msg
egressions.
> Conversely, if GCC retains the policy of updating its Libtool files at
> most once every decade, then we can't help them, no matter what bug
> we're talking about.
Right. The problem was that they had modified their local version of
libtool-1.4.x, and were theref
On Wed, 25 Apr 2007 23:57:13 +0200, "Bruno Haible" <[EMAIL PROTECTED]>
[Lots of good comments...snipped]
As I was the originator of this change (though not its final form), and
because Ralf has already committed it to libtool cvs, I'll generate and
test an additional pat
gcj uses libltdl primarily as a
> portable wrapper for dlopen. 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'.
> Also,
> libgcj has some local libltdl patches as well.
Then they sh
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 someb
e difficulties and ripples are why I originally thought
'eliminate the wrapper script 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 wa
n, and only when done I asked myself
> this, more radical question: we go great lengths here to find out a
> name. Iff we have a *.la file to go with the implib, can't we just
> *know* the name? I mean, we produced that thing, it has the expected
> name, no? That's what the
jects that are then linked in
to the executable (or DLL). With binutils, you can instead create a
second file with the following content:
1 24 MOVEABLE PURE ".manifest"
and then
$ windres .rc .rc.o
$ ld -o .exe .exe .rc.o
$ mv .exe .exe
But that's overkill for the libtool cwrappers
generate the manifest file all by itself, regardless 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
> >
Your mail to 'Libtool' with the subject
(no subject)
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message has implicit destination
Either the message will get posted to the list, or you will receive
notification of the m
The results of your email command are provided below. Attached is your
original message.
No commands were found in this message. To obtain instructions, send a
message containing just the word "help".
- Done.
--- Begin Message ---
--- End Message ---
11 matches
Mail list logo