While looking though ltmain source code i've stumbled upon this egrep
invocation:
$EGREP ' (_head_[A-Za-z0-9_]+_[ad]l*|[A-Za-z0-9_]+_[ad]l*_iname)$'
I've tried to see how it behaves on some import libraries that i have, and it
turned out that i could never get it to detect the iname lines, unless
Follow-up Comment #4, sr #108559 (project libtool):
Care to close this bug?
___
Reply to this item at:
http://savannah.gnu.org/support/?108559
___
Message sent via/by Savannah
Follow-up Comment #11, sr #108558 (project libtool):
Don't you want to close this bug?
___
Reply to this item at:
http://savannah.gnu.org/support/?108558
___
Message sent via/by Savannah
Follow-up Comment #9, sr #108558 (project libtool):
I have attached a patch that does the safe-safe-safe version.
Does it work for you?
Yes, it seems that it does.
___
Reply to this item at:
http://savannah.gnu.org/support/?108558
Follow-up Comment #2, sr #108558 (project libtool):
I was not aware of the extent to which Cygwin is mangling
commandlines of pure-W32 programs it runs (since i don't
really use Cygwin; i do know it does some kind of conversion;
apparently, only in one direction). Evidently, it does not
replace
Follow-up Comment #4, sr #108558 (project libtool):
Well, in MSYS2 you can simply do:
nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble
and get satisfactory results (file name and 'No such file'
in the output).
Can't say anything about MSYS1, haven't used it for some time.
That
Follow-up Comment #2, sr #108559 (project libtool):
Yeah, that worked
___
Reply to this item at:
http://savannah.gnu.org/support/?108559
___
Message sent via/by Savannah
Follow-up Comment #6, sr #108558 (project libtool):
Crap.
How about just opening a file that is known to not to exist?
Alternatively, give nm a real file that is at least 1 byte long (binutils nm
checks for filesize being 1 and fails quietly; having 1 byte makes it say
filename (which is
URL:
http://savannah.gnu.org/support/?108558
Summary: libtool nm test does not really work for W32
versions of nm
Project: GNU Libtool
Submitted by: lrn
Submitted on: Fri 02 May 2014 05:10:04 AM GMT
Category: None
URL:
http://savannah.gnu.org/support/?108559
Summary: libtool binary wrappers fall prey to aggressive
optimizations
Project: GNU Libtool
Submitted by: lrn
Submitted on: Fri 02 May 2014 05:16:44 AM GMT
Category: None
Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined
gcc now says something like this:
gcc.exe: error: unrecognized option '-no-undefined'
Before 4.6.0 it was possible to do that, and gcc said only this:
gcc.exe: unrecognized option '-no-undefined'
That is, unrecognized option
On 18.03.2011 23:51, Vincent Torri wrote:
On Fri, 18 Mar 2011, LRN wrote:
Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined
gcc now says something like this:
gcc.exe: error: unrecognized option '-no-undefined'
Before 4.6.0 it was possible to do that, and gcc said only
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive
I have a project that uses autoconf/automake/libtool, and it produces
shared libraries (on Windows that would be .dll) and static libraries
(.a). Which modifications are necessary for it to start outputing .lib
libraries (the ones that could be linked with link.exe) along with
.dll's? I can hack
14 matches
Mail list logo
