Does libtool include all options with -M?

Question

I am trying to track the failure of a map file connection in Solaris. A missing map file causes the following error when I try to run a self test:

$ ./cryptestcwd v ld.so.1: cryptestcwd: fatal: /export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability (CA_SUNW_HW_1) unsupported: 0x4800000 [ AES SSE4.1 ] Killed 

I got to this Automake rule. libcryptopp_la_LINK , which I believe is a shared object, is missing AM_LDFLAGS . AM_LDFLAGS contains the -M cryptopp.mapfile parameter.

 libcryptopp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(libcryptopp_la_LDFLAGS) $(LDFLAGS) -o $@ 

I tried to fix it with sed after configure :

 libcryptopp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(libcryptopp_la_LDFLAGS) -M cryptopp.mapfile $(LDFLAGS) -o $@ 

I confirmed that sed successful, but the same test fails again. When invoking commands, -M <mapfile> missing.

the manual for libtool talks about the -M arguments in Cygwin, but not in Solaris (and the discussion applies only to GCC and not to other compilers such as IBM XL C / C ++, Sun C / C ++ and LLVM Clang):

Note that you also need to make sure that standard Unix directories (e.g. / bin, / lib, / usr, / etc) are displayed in the root of the disk. This means that you must install Cygwin directly in the root directory C: / (or D: /, or E: / etc.), Instead of the recommended installation in C: / cygwin /. In addition, all file names used in the assembly system must be relative, symbolic links should not be used in source or assembly trees, and all -M * options for gcc except -MMD should be avoided.

There is no other mention of -M .

And there is no diagnosis, for example, "Removing the -M <mapfile> for Sun Linker" or "Warning: libtool does not understand the -M <mapfile> ".

My question is: libtool disard -M and its arguments for some reason?

Answer 1

Libtool robs some link options when creating a library. The manual explains :

When creating a shared library, but not when compiling or creating the program, libtool discards some flags from the command line provided by the User. This is because flags unknown to libtool may interfere with the creation of the library or additional support from libtool is required, and lowering flags is usually a conservative choice for a successful build.

Personally, I find the justification for such behavior to be a little cavalier, and I also think that this guarantees a warning from libtool when this happens, but if you do not care to raise a question against it, which is pretty much controversial.

The experiment shows that -M indeed one of the options that libtool shares. In particular, if I specify LDFLAGS containing the -M parameter in the make command line, then I can notice that it is reflected in the output of make when the libtool link is launched, but not in libtool own echo of the link command, which is actually executed:

$ make LDFLAGS = "- M mapfile"

/bin/sh./libtool --tag = CC --mode = link gcc -g -O2 -M mapfile -o libmylib.la -rpath / usr / local / lib x. lo y.lo

libtool: link: gcc -shared -fPIC -DPIC.libs / xo.libs / yo -O2 -Wl, -soname -Wl, libmylib.so.0 -o.libs / libmylib.so.0.0.0

libtool docs offer two workarounds for passing link parameters that would otherwise be deleted:

• For alternative linker options, you can use one or more of the -Wl, or -Xlinker to pass your options through libtool and the linker driver directly to the linker. For example,

   LDFLAGS=-Wl,-M,cryptopp.mapfile 

• For options specifically designed for the linker driver, documents suggest adding flags to the compiler driver command (CC = "gcc -M mapfile"), but this is inefficient because the $(CC) variable expands to make to form the libtool command line, leaving any options expressed in it, subjected to libtool for removal.

In addition, there is

• The parameter is -XCClinker , by which parameters can be passed to the linker driver (unlike the linker itself), but its behavior seems a little bizarre: it seems to ignore parameters that do not start with a hyphen (for example, the name of your map file).