Making .lib import libraries with libtool

[LRN]

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 configure script and add calls to lib.exe, but that
doesn't seem right, and i would rather try doing that in configure.ac.


___
http://lists.gnu.org/mailman/listinfo/libtool

Linking together .dll using .a static libraries

[LRN]

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 import" or "x86 DLL", but not "x86 archive static".




___
http://lists.gnu.org/mailman/listinfo/libtool

-no-undefined vs gcc 4.6.0

[LRN]

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 was not considered a show-stopper, and 
everything worked just fine - the option, being part of LDFLAGS, 
eventually reached libtool, and libtool were taking the clue to disallow 
undefined symbols. Not anymore. Now i have to pass 
LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but 
libtool is unable to recognize this argument in such form and simply 
refuses to build shared libraries outright.
Not sure if it's a bug or a feature, and how to work through that 
without making groundbreaking changes in software packages that use libtool.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: -no-undefined vs gcc 4.6.0

[LRN]

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 this:
gcc.exe: unrecognized option '-no-undefined'
That is, unrecognized option was not considered a show-stopper, and 
everything worked just fine - the option, being part of LDFLAGS, 
eventually reached libtool, and libtool were taking the clue to 
disallow undefined symbols. Not anymore. Now i have to pass 
LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but 
libtool is unable to recognize this argument in such form and simply 
refuses to build shared libraries outright.
Not sure if it's a bug or a feature, and how to work through that 
without making groundbreaking changes in software packages that use 
libtool.


I think that you have to pass -no-undefined to the ***_LDFLAGS 
variable of your library:


lib_LTLIBRARIES = libproject.la
libproject_la_LDFLAGS = -no-undefined

or, globally:

AM_LDFLAGS = -no-undefined

it has always worked for me, without gcc warning.


It's not my library. I'm compiling mpc-0.8.2

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: -no-undefined vs gcc 4.6.0

[LRN]

On 19.03.2011 0:17, Vincent Torri wrote:



On Sat, 19 Mar 2011, LRN wrote:


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 this:
gcc.exe: unrecognized option '-no-undefined'
That is, unrecognized option was not considered a show-stopper, and 
everything worked just fine - the option, being part of LDFLAGS, 
eventually reached libtool, and libtool were taking the clue to 
disallow undefined symbols. Not anymore. Now i have to pass 
LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but 
libtool is unable to recognize this argument in such form and 
simply refuses to build shared libraries outright.
Not sure if it's a bug or a feature, and how to work through that 
without making groundbreaking changes in software packages that use 
libtool.


I think that you have to pass -no-undefined to the ***_LDFLAGS 
variable of your library:


lib_LTLIBRARIES = libproject.la
libproject_la_LDFLAGS = -no-undefined

or, globally:

AM_LDFLAGS = -no-undefined

it has always worked for me, without gcc warning.


It's not my library. I'm compiling mpc-0.8.2


ok. Anyway you have to pass -Wl,-no-undefined. It's an option for the 
linker [1], not for gcc [2]


Vincent Torri

[1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld
[2] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
I *know* that it's a linker option. And i know that i have to pass it 
with -Wl because of that. What i do not know is how to make libtool see 
it when it is passed like that.


Finally got it to work with `make libmpc_la_LDFLAGS="-version-info 2:0:0 
-no-undefined"', because mpc does not use AM_LDFLAGS in the link command 
that is used to build libmpc (mpc devs are probably the ones to blame, 
but right now i just want to make it work). Although i've found no way 
to pass such an option with spaces to `make' from a variable expansion 
(i.e. `make $opts'), so i've had to hard-code it into make invocation 
instead.


I expect to find a lot of libtool-using projects that will require such 
hacks or workarounds, because `unrecognized option  '-no-undefined'' is 
very common.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: -no-undefined vs gcc 4.6.0

[LRN]

On 19.03.2011 13:29, Vincent Torri wrote:



On Sat, 19 Mar 2011, LRN wrote:


On 19.03.2011 0:17, Vincent Torri wrote:



On Sat, 19 Mar 2011, LRN wrote:


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 this:
gcc.exe: unrecognized option '-no-undefined'
That is, unrecognized option was not considered a show-stopper, 
and everything worked just fine - the option, being part of 
LDFLAGS, eventually reached libtool, and libtool were taking the 
clue to disallow undefined symbols. Not anymore. Now i have to 
pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of 
view, but libtool is unable to recognize this argument in such 
form and simply refuses to build shared libraries outright.
Not sure if it's a bug or a feature, and how to work through that 
without making groundbreaking changes in software packages that 
use libtool.


I think that you have to pass -no-undefined to the ***_LDFLAGS 
variable of your library:


lib_LTLIBRARIES = libproject.la
libproject_la_LDFLAGS = -no-undefined

or, globally:

AM_LDFLAGS = -no-undefined

it has always worked for me, without gcc warning.


It's not my library. I'm compiling mpc-0.8.2


ok. Anyway you have to pass -Wl,-no-undefined. It's an option for 
the linker [1], not for gcc [2]


Vincent Torri

[1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld
[2] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
I *know* that it's a linker option. And i know that i have to pass it 
with -Wl because of that. What i do not know is how to make libtool 
see it when it is passed like that.


Finally got it to work with `make libmpc_la_LDFLAGS="-version-info 
2:0:0 -no-undefined"', because mpc does not use AM_LDFLAGS in the 
link command that


i'm wondering if you ever read my first answer...

Vincent


I did. I thought you were referring to Makefile.am

___
http://lists.gnu.org/mailman/listinfo/libtool

[sr #108558] libtool nm test does not really work for W32 versions of nm

[LRN]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Microsoft Windows

___

Details:

libtool.m4 contains the following code:

# Check to see if the nm accepts a BSD-compat flag.
# Adding the 'sed 1q' prevents false positives on HP-UX, which says:
#   nm: unknown option "B" ignored
# Tru64's nm complains that /dev/null is an invalid object file
case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
*/dev/null* | *'Invalid file or object type'*)
  lt_cv_path_NM="$tmp_nm -B"
  break 2
  ;;
*)
  case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
  */dev/null*)
lt_cv_path_NM="$tmp_nm -p"
break 2
;;
  *)
lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
continue # so that we can try to find one that supports BSD flags
;;
  esac
  ;;
esac

This does not work if `nm' in question is built for W32, because `/dev/null'
gets mangled into `nul', and `nul' does not behave the same way (it can be
stat()'ed successfully and looks like a zero-size file to stat()).
Even if binutils are patched to do a more thorough check (for example, stricmp
(file_name, "nul") or && isatty(open (file_name, ...))), the file name
reported in the error message is `nul', not `/dev/null', so the case statement
here won't match.

AFAIU, this bug is as old as this code (which, i guess, makes it quite old),
but it was masked by the fact that /usr/bin/nm (MSYS/Cygwin nm) does pass this
test, and it's sufficiently compatible (for the purpose of parsing object
files) for this not to matter.

Things start to blow up when MinGW nm and MSYS/Cygwin nm are not completely
compatible (for example, when MinGW binutils and gcc are built with LTO
support, and MSYS/Cygwin binutils&gcc are not).




___

Reply to this item at:

  <http://savannah.gnu.org/support/?108558>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

[LRN]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

When building binary wrappers (say, for W32), libtool puts a MAGIC constant
string into them. Later on libtool greps the program for this string to see
whether this is a wrapper or a real program.

However, MAGIC string is not used in the program in any way, and gcc may
remove it. This does happen when building with -flto.

My proposal would be to make use of the string somehow to fool gcc into
leaving it alone. For example, this call:

   lt_fatal (__FILE__, __LINE__,
"unrecognized %s option: '%s'",
ltwrapper_option_prefix, argv[i]);

can be changed like this:

   lt_fatal (__FILE__, __LINE__,
"unrecognized %s option: '%s'\0%s",
ltwrapper_option_prefix, argv[i], MAGIC_EXE);





___

Reply to this item at:

  <http://savannah.gnu.org/support/?108559>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108558] libtool nm test does not really work for W32 versions of nm

[LRN]

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 /dev/null with nul. In which case - yes, this only
affects MSYS.

> It would be easier to work around this if the native MinGW nm
> reported some kind of error message involving 'NUL', so that
> the case pattern could be extended.
I can come up with a fix for binutils. However, upstreaming it
would be difficult, i expect. In fact i did make a patch: right
now my hack makes it open the file, feed the fd to isatty(), and if
it turns to not to be a real file, it checks whether its name
is "nul" and replaces that with "/dev/null", so the script gets
the output it expects. As you may imagine, this is never going to
be accepted upstream.

The isatty() part might be acceptable (though i expect someone
to point out that opening files may be a performance hit), and
in that case libtool can just check for 'nul'.

> Granted, that would not fix
> the bug for old tool chains, but the bug has existed for a very
> long time and you can always work around it with an explicit
> NM=...
Yes. Not only NM=..., but you can also let it fall back to
*-pc-msys-nm, which totally worked, and may even continue to
work for most users (which have matching MSYS and MinGW toolchains).

> The alternative is for libtool use some other non-existant
> or otherwise special file on MSYS, when it is trying to work out
> if nm supports -B. I don't know what that file would be though,
> and it always feels a little bit icky to special case things. 

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108558] libtool nm test does not really work for W32 versions of nm

[LRN]

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 would also work on MSYS1.

> However, I had an idea. Anyone against using
> "$tmp_nm" -B ///dev/null
> everywhere? "///foo" and "/foo" should be equivalent according to
> Posix. We should still check for "/dev/null" in the output,
> methinks... 

Neat! I like that.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

[LRN]

Follow-up Comment #2, sr #108559 (project libtool):

Yeah, that worked

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108558] libtool nm test does not really work for W32 versions of nm

[LRN]

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 what we want) and "File truncated").

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108558] libtool nm test does not really work for W32 versions of nm

[LRN]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

[LRN]

Follow-up Comment #4, sr #108559 (project libtool):

Care to close this bug?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108558] libtool nm test does not really work for W32 versions of nm

[LRN]

Follow-up Comment #11, sr #108558 (project libtool):

Don't you want to close this bug?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

Does libtool need to escape plus signs in egrep expressions?

[LRN]

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 i escape
the plus sign.

Are you sure this actually works? Note that the function that does this is only
used in rather exotic corner-cases (old dlltool and/or ms dumpbin being in
use), so it's plausible that it could have been broken since 2010, when it was
added.





signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool