On Aug 21 22:43:12, m...@mansr.com wrote: > Jan Stary <h...@stare.cz> writes: > > >> However, the build eventually fails with a linking error: > >> > >> /bin/sh ../libtool --tag=CC --mode=link cc -g -O2 > >> -fstack-protector-strong -Wall -Wmissing-prototypes -Wstrict-prototypes > >> -avoid-version -module -L/usr/local/lib -fstack-protector-strong > >> -Wl,--as-needed -o sox sox.o libsox.la -lm > >> libtool: link: cc -g -O2 -fstack-protector-strong -Wall > >> -Wmissing-prototypes -Wstrict-prototypes -fstack-protector-strong > >> -Wl,--as-needed -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng > >> -lltdl -lao -lgsm -lid3tag -lz -lmad -lmp3lame -ltwolame -lopusfile -lopus > >> -lsndio -lvorbisfile -lwavpack -lcrypto -lsndfile -lFLAC -lvorbisenc > >> -lvorbis -logg -lm -Wl,-rpath,/home/hans/lib -Wl,-rpath,/usr/local/lib > >> ld: error: undefined symbol: lsx_malloc > >> [...] > >> > >> Indeed, none of the input files defines lsx_malloc; > >> it is defined in libsox.so > >> > >> $ nm .libs/libsox.so.3.0 | grep lsx_malloc > >> 00042a30 T lsx_malloc > >> > >> but that is not one of the inputs. Adding .libs/libsox.so.3.0 > >> as an input to the above line make it link as expected. > > > > Hm. but the "-L./.libs -lsox" should take care of that. > > Is it because of the extra -L/usr/local/lib? When building > > without any extra LDFLAGS, that line is > > > > cc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes > > -Wstrict-prototypes -fstack-protector-strong -Wl,--as-needed -o .libs/sox > > sox.o -L ./.libs -lsox > > -L/usr/local/lib -lFLAC -lopusfile -lopus -lsndio -lvorbisenc -lvorbisfile > > -lvor > > bis -logg -lm -Wl,-rpath,/home/hans/lib -Wl,-rpath,/usr/local/lib > > That's seems to be parts of several commands. Did the mouse slip when > you copied it?
Sorry, that's one broken line:
cc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes
-Wstrict-prototypes -fstack-protector-strong -Wl,--as-needed -o .libs/sox sox.o
-L ./.libs -lsox -L/usr/local/lib -lFLAC -lopusfile -lopus -lsndio -lvorbisenc
-lvorbisfile -lvorbis -logg -lm -Wl,-rpath,/home/hans/lib
-Wl,-rpath,/usr/local/lib
> > and it links fine.
> >
> > Is it because of the _order_ of the -L options?
>
> For each -l option, the directories specified with -L options preceding
> it are searched in order until a match is found.
In that case,
-o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox
will find /usr/local/lib/libsox.so first,
i.e. the one from a previous installation.
That seems wrong.
> Unless there are
> conflicting libraries in different locations, the order doesn't matter.
There is /usr/local/lib/libsox.so from the already installed sox,
and there is .libs/libsox.so ; at any rate, the sox being built
should probably not be linked against the old library.
> > Note that with LDFLAGS=/usr/local/lib, the order is
> >
> > -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox [etc]
which seems wrong, if the above is true.
> > but without LDFLAGS it's
> >
> > -o .libs/sox sox.o -L ./.libs -lsox -L/usr/local/lib -lFLAC [etc]
Which seems correct: fond libsox in .libs,
and then find flac etc in /usr/local/lib
> How did that -L/usr/local/lib get there?
./configure CPPFLAGS=-I/usr.local/include LDFLAGS=-L/usr/local/lib
It seems that specifying LDFLAGS puts the -L in a wrong place
in the eventual cc -o linking line.
> Please send me your config.log so I can see what's going on.
Attached.
> It all works fine on my VM with this environment and no configure options:
./configure --help says
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
so that's what I'm doing (and that's what has worked for
the OpenBSD port of SoX for years now).
> AUTOCONF_VERSION=2.69
> AUTOMAKE_VERSION=1.16
Same here:
env AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 autoreconf -i
But after ./configure is created, these should not be needed any more.
> CC=cc
It is a damn shame, but one has to say so;
otherwise the build system will poick gcc instead of cc.
> C_INCLUDE_PATH=/usr/local/include
> LIBRARY_PATH=/usr/local/lib
I never used any of these.
Are they docummented anywhere?
$ grep -Fr C_INCLUDE_PATH *
Jan
config.log.gz
Description: application/gunzip
_______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
