1
votes

Perhaps there is something really basic I don't know, but I'm facing a very weird behaviour: after my libtool shared library was properly built, it is deleted immediately after.

Basically, this Makefile.am:

ACLOCAL_AMFLAGS = -I m4 --install

lib_LTLIBRARIES =

if BUILD_WIRINGPI_STUB
    lib_LTLIBRARIES += libwiringPiStub.la

    # headers to be installed
    include_HEADERS = \
    src/wiringPi-stub/wiringPi.h
endif

LIBTOOL_DEPS = @LIBTOOL_DEPS@

# libwiringPiStub.{so,a}
libwiringPiStub_la_LDFLAGS = -rpath '$(libdir)' -version-info $(WIRINGPI_STUB_SOVERSION)
libwiringPiStub_la_SOURCES = src/wiringPi-stub/wiringPi.c

pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = src/wiringPi-stub/libwiringPiStub.pc

produces this build history, which looks ok:

% make libwiringPiStub.la
depbase=`echo src/wiringPi-stub/wiringPi.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
    /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT src/wiringPi-stub/wiringPi.lo -MD -MP -MF $depbase.Tpo -c -o src/wiringPi-stub/wiringPi.lo src/wiringPi-stub/wiringPi.c &&\
    mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -g -O2 -MT src/wiringPi-stub/wiringPi.lo -MD -MP -MF src/wiringPi-stub/.deps/wiringPi.Tpo -c src/wiringPi-stub/wiringPi.c  -fno-common -DPIC -o src/wiringPi-stub/.libs/wiringPi.o
/bin/sh ./libtool  --tag=CC   --mode=link gcc  -g -O2 -rpath '/usr/local/lib' -version-info 1:0:0  -o libwiringPiStub.la  src/wiringPi-stub/wiringPi.lo  -lpthread -lm 
libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libwiringPiStub.1.dylib  src/wiringPi-stub/.libs/wiringPi.o   -lpthread -lm  -g -O2   -install_name  /usr/local/lib/libwiringPiStub.1.dylib -compatibility_version 2 -current_version 2.0 -Wl,-single_module
libtool: link: (cd ".libs" && rm -f "libwiringPiStub.dylib" && ln -s "libwiringPiStub.1.dylib" "libwiringPiStub.dylib")
libtool: link: ( cd ".libs" && rm -f "libwiringPiStub.la" && ln -s "../libwiringPiStub.la" "libwiringPiStub.la" )

In facts, nothing is installed in my $(libdir) with make install, either are the header file in the include dir.

This is the output of the make install execution:

% make install                       
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
 /usr/local/bin/gmkdir -p '/usr/local/lib/pkgconfig'
 /usr/local/bin/ginstall -c -m 644 src/wiringPi-stub/libwiringPiStub.pc '/usr/local/lib/pkgconfig'

In fact, only the .pc file is actually moved in position. What can I try to resolve this?

1
Are you sure you're looking in the right libdir and includedir? If you do not override the default prefix or override those specific installation directories when you configure the project, then the defaults should be /usr/local/lib and /usr/local/include, repsectively. - John Bollinger
Does the make install command complete successfully? Can you present its output? - John Bollinger
I've added the output of make install, as @JohnBollinger suggestion was unfortunately not successful - Gabriele B
My best guess would be that the BUILD_WIRINGPI_STUB conditional is evaluating to false when you configure the project. That would not prevent you from building target libwiringPiStub.la by explicitly specifying its name to make, as your example shows, but it and its header would not be included in installs. In that case, you should also see that the library does not get built unless you do specifically name it -- that is, it would not be built by just make or make all. - John Bollinger

1 Answers

2
votes

There does not appear to be anything inherently wrong with the Automake input file presented, and the fact that target libwiringPiStub.la can be built by explicitly requesting that with make libwiringPiStub.la tends to support that conclusion.

At the same time, the fact that make install completes successfully without even attempting to install the library or the associated header strongly suggests that project configuration resulted in them not being included in the values of the lib_LTLIBRARIES and include_HEADERS variables. That would fall out naturally from the BUILD_WIRINGPI_STUB Automake conditional evaluating to false at configure time, but I see no reason to think that the same would occur if that conditional evaluated to true. Thus, that's where I expect you to find the problem.

You can verify that the conditional is responsible by looking at the generated Makefile. The body of the conditional will be present in the Makefile either way, but if the conditional evaluates to false then it will be commented out.