Re: [SoX-devel] Build system cleanup
On Aug 24 12:04:11, m...@mansr.com wrote: > Jan Stary writes: > > > We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH > > into ./configure's environment produces a working link command; > > passing CPPFLAGS and LDFLAGS to ./configure also used to produce > > a working command, but now produces a failing link line; > > the position of -L seems to be the difference. > > Both ways work fine on my OpenBSD system (clean install + lame etc). > There is no difference in behaviour between the master and new-build > branches. Can you please post the complete script(1) for each of env CC=cc C_INCLUDE_PATH=/usr/local/include LIBRARY_PATH=/usr/local/lib \ ./configure make V=1 and ./configure CC=cc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make V=1 on both master and new-build? Because the difference between the two calls (which is, eventually, the difference between the ultimate link command) seems to be exactly the problem on my system. Jan ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
On Aug 23 23:55:51, h...@stare.cz wrote: > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...] > > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...] > > > > > > The first works, the second does not. > > > The only difference between the two is the place > > > where the extra -L/usr/local/lib gets added, > > > as described in the previous emails. > > And it seems libtool itself is the one who breaks it. > This is the failing line again: > > /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 -Wl,--as-needed -o sox sox.o > libsox.la -lm > > Notice the "-L/usr/local/lib -Wl,--as-needed". > The "-L/usr/local/lib" part comes from the configure arg: > > ./configure CC=cc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib > > The "-Wl,--as-needed" comes from > > $ grep as-needed configure.ac > AX_APPEND_LINK_FLAGS([-Wl,--as-needed]) > > That results in the following line in src/Makefile: > > LDFLAGS = -L/usr/local/lib -Wl,--as-needed > > and that's what is passed in the above command line. Now, libtool > apparently preprocesses the line into something else; in particular, > it reorders the options. The very next command is: > > libtool: link: cc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes > -Wstrict-prototypes -Wl,--as-needed -o .libs/sox sox.o -L/usr/local/lib > -L./.libs -lsox -lpng -lltdl -lao -lgsm -lmad -lmp3lame -ltwolame -lid3tag > -lz -lopusfile -lopus -lsndio -lvorbisfile -lwavpack -lcrypto -lsndfile > -lFLAC -lvorbisenc -lvorbis -logg -lm -Wl,-rpath,/usr/local/lib > > Notice where the -L/usr/local/lib has been moved. > As described previously, if it comes after -lsox > instead of before it, it links just fine. That being said, the same problem is present in the master branch, but it works in 14.4.2, where the libtool line is bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wtraditional-co nversion -g -O2 -fstack-protector -Wall -W -Wmissing-prototypes -Wstrict-protot ypes -pedantic -avoid-version -module -L/usr/local/lib -o sox sox.o libsox.la -lm which becomes (without 'silent') libtool: link: cc -Wtraditional-conversion -g -O2 -fstack-protector -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lltdl -lpng -lao -lgsm -lmad -lid3tag -lz -lmp3lame -ltwolame -lopusfile -lopus -lsndio -lvorbisfile -lwavpack -lcrypto -lsndfile -lFLAC -lvorbisenc -lvorbis -logg -lm -Wl,-rpath,/home/hans/lib -Wl,-rpath,/usr/local/lib ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] ladspa support detection
Jan Stary writes: > Running the new ./configure (from the new-build branch) > autodetects LADSPA as enabled: > > LADSPA effect plugins yes > > I don't have anything ladspa-related installed > (or is nothing particular required to "enable" ladspa?) You don't need anything besides dlopen() for it to work. -- Måns Rullgård ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
Jan Stary writes: > We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH > into ./configure's environment produces a working link command; > passing CPPFLAGS and LDFLAGS to ./configure also used to produce > a working command, but now produces a failing link line; > the position of -L seems to be the difference. Both ways work fine on my OpenBSD system (clean install + lame etc). There is no difference in behaviour between the master and new-build branches. -- Måns Rullgård ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] NSP support
Updated version Ar Domh 2 Lún 2020 ag 01:26, scríobh Jim O'Regan : > Hi. > > I did this a few years ago to convert some old files created with > Wavesurfer. I've just checked that the patch applies. It's also in a branch > on github, here: https://github.com/jimregan/sox-nsp/tree/nsp-flat > NSP.patch Description: Binary data ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
> It all works fine on my VM with this environment and no configure options: > AUTOCONF_VERSION=2.69 > AUTOMAKE_VERSION=1.16 > CC=cc > C_INCLUDE_PATH=/usr/local/include > LIBRARY_PATH=/usr/local/lib I see you have changed the install instructions in the INSTALL file (slapping them onto the Aug 14 commit without mentioning it or reflecting it in the commit message). There is a few problems: 1. On some systems, in particular OpenBSD, the autoreconf insists that 'libtool' is the GNU libtool (of course). So the requirement to have autoconf, automake and autoconf-archive probably needs to be augmented with GNU libtool; otherwise, $ env AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 autoreconf -i configure.ac:28: installing './compile' configure.ac:16: installing './install-sh' configure.ac:16: installing './missing' lpc10/Makefile.am:8: error: Libtool library used but 'LIBTOOL' is undefined lpc10/Makefile.am:8: The usual way to define 'LIBTOOL' is to add 'LT_INIT' lpc10/Makefile.am:8: to 'configure.ac' and run 'aclocal' and 'autoconf' again. lpc10/Makefile.am:8: If 'LT_INIT' is in 'configure.ac', make sure lpc10/Makefile.am:8: its definition is in aclocal's search path. lpc10/Makefile.am: installing './depcomp' src/Makefile.am:26: error: Libtool library used but 'LIBTOOL' is undefined src/Makefile.am:26: The usual way to define 'LIBTOOL' is to add 'LT_INIT' src/Makefile.am:26: to 'configure.ac' and run 'aclocal' and 'autoconf' again. src/Makefile.am:26: If 'LT_INIT' is in 'configure.ac', make sure src/Makefile.am:26: its definition is in aclocal's search path. autoreconf-2.69: automake failed with exit status: 1 2. "Run ./configure --help for a complete list of options." recommends to set the CC and CFLAGS and LDFLAGS etc as the arguments to ./configure, and never mentions C_INCLUDE_PATH or LIBRARY_PATH. 3. Later, the INSTALL manual recommends export CPATH=/usr/local/include export LIBRARY_PATH=/usr/local/lib as opposed to C_INCLUDE_PATH. 4. The other install manuals (README.win32, cygbuild. osxbuild - not sure how much relevant these are) still use thee ./configure CFLAGS=... syntax Jan ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
Jan Stary writes: >> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...] >> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...] >> > >> > The first works, the second does not. >> > The only difference between the two is the place >> > where the extra -L/usr/local/lib gets added, >> > as described in the previous emails. > > And it seems libtool itself is the one who breaks it. > This is the failing line again: > > /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 -Wl,--as-needed -o sox sox.o > libsox.la -lm > > Notice the "-L/usr/local/lib -Wl,--as-needed". > The "-L/usr/local/lib" part comes from the configure arg: > > ./configure CC=cc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib > > The "-Wl,--as-needed" comes from > > $ grep as-needed configure.ac > AX_APPEND_LINK_FLAGS([-Wl,--as-needed]) > > That results in the following line in src/Makefile: > > LDFLAGS = -L/usr/local/lib -Wl,--as-needed > > and that's what is passed in the above command line. Now, libtool > apparently preprocesses the line into something else; in particular, > it reorders the options. The very next command is: > > libtool: link: cc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes > -Wstrict-prototypes -Wl,--as-needed -o .libs/sox sox.o -L/usr/local/lib > -L./.libs -lsox -lpng -lltdl -lao -lgsm -lmad -lmp3lame -ltwolame -lid3tag > -lz -lopusfile -lopus -lsndio -lvorbisfile -lwavpack -lcrypto -lsndfile > -lFLAC -lvorbisenc -lvorbis -logg -lm -Wl,-rpath,/usr/local/lib > > Notice where the -L/usr/local/lib has been moved. > As described previously, if it comes after -lsox > instead of before it, it links just fine. None of this has changed. The problem is that you have an old libsox in /usr/local/lib, and with that -L flag early in the command, it takes precedence over the just-built libsox, causing the link to fail. If you're building the same version, it won't matter which one the linker finds, so it succeeds. This whole issue is unique to OpenBSD. On Linux and FreeBSD the link command uses the full filename of libsox, so it isn't searched for in the -L locations. -- Måns Rullgård ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
On Aug 24 13:19:36, m...@mansr.com wrote: > Jan Stary writes: > > >> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...] > >> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...] > >> > > >> > The first works, the second does not. > >> > The only difference between the two is the place > >> > where the extra -L/usr/local/lib gets added, > >> > as described in the previous emails. > > > > And it seems libtool itself is the one who breaks it. > > This is the failing line again: > > > > /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 -Wl,--as-needed -o sox sox.o > > libsox.la -lm > > > > Notice the "-L/usr/local/lib -Wl,--as-needed". > > The "-L/usr/local/lib" part comes from the configure arg: > > > > ./configure CC=cc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib > > > > The "-Wl,--as-needed" comes from > > > > $ grep as-needed configure.ac > > AX_APPEND_LINK_FLAGS([-Wl,--as-needed]) > > > > That results in the following line in src/Makefile: > > > > LDFLAGS = -L/usr/local/lib -Wl,--as-needed > > > > and that's what is passed in the above command line. Now, libtool > > apparently preprocesses the line into something else; in particular, > > it reorders the options. The very next command is: > > > > libtool: link: cc -g -O2 -fstack-protector-strong -Wall > > -Wmissing-prototypes -Wstrict-prototypes -Wl,--as-needed -o .libs/sox sox.o > > -L/usr/local/lib -L./.libs -lsox -lpng -lltdl -lao -lgsm -lmad -lmp3lame > > -ltwolame -lid3tag -lz -lopusfile -lopus -lsndio -lvorbisfile -lwavpack > > -lcrypto -lsndfile -lFLAC -lvorbisenc -lvorbis -logg -lm > > -Wl,-rpath,/usr/local/lib > > > > Notice where the -L/usr/local/lib has been moved. > > As described previously, if it comes after -lsox > > instead of before it, it links just fine. > > None of this has changed. The problem is that you have an old libsox in > /usr/local/lib, and with that -L flag early in the command, it takes > precedence over the just-built libsox, causing the link to fail. This seems to be the case - together with GNU libtool putting that -L/usr/local/lib _before_ the -L./.libs which would link with the "new" libsox. (And, indeed, $ nm /usr/local/lib/libsox.so.4.0 | grep lsx_malloc $ nm src/.libs/libsox.so.3.0 | grep lsx_malloc 00042f60 T lsx_malloc which was the actual unresolved symbol, among others). I can confirm that deleting the previous version of sox (installed in /usr/local/ via the OpenBSD sox-14.4.2p5 port) makes that problem go away; or, better put, masks the bug by removing the condition under which is shows. > This whole issue is unique to OpenBSD. Having a previous version installed while a new one is being built is to be expected, right? Searching for -lsox in the -L path is also perfectly normal. As we now know, it is the order of the -L options introduced by GNU libtool that breaks it. Your "clean" VM is a special case in that it does not have a previous version installed (as opposed to my screwed up, misconfigured machine). When you install the previous sox 14.4.2 (pkg_add sox), does the ./configure CC=cc CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make V=1 build still work? > On Linux and FreeBSD the link command uses the full filename of libsox, > so it isn't searched for in the -L locations. I didn't get to FreeBSD testing yet, but on NetBSD (where the build fails in other interesting ways), it's libtool: link: gcc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes -Wstrict-prototypes -fopenmp -Wl,--as-needed -o .libs/sox sox.o ./.libs/libsox.so -L/usr/pkg/lib -lmagic /usr/pkg/lib/libFLAC.so /usr/pkg/lib/libopusfile.so /usr/pkg/lib/libopus.so /usr/pkg/lib/libvorbisenc.so /usr/pkg/lib/libvorbisfile.so /usr/pkg/lib/libvorbis.so /usr/pkg/lib/libogg.so -lm -fopenmp -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib So even some of the external libraries are linked via absolute paths - seems to be precisely those detected by pkg-config (not sure what the point of pkg-config --libs is then); the others (-lm -lmagic) are found in the -L path. The linking commands are not invented by Linux or FreeBSD or OpenBSD - they are what libtool or ./configure (or whatever it is inside the auto* maze) put into the actual Makefile(s). If I understand the idea of autotools at all, the supposed position of libtool is "Yo, I know how any given system/linker links; so I can issue the right linking commands for this system/linker right here, man". What *is* unique about OpenBSD, then, is that GNU libtool does in fact not know how to link here. Does that make sense? ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
Jan Stary writes: >> It all works fine on my VM with this environment and no configure options: >> AUTOCONF_VERSION=2.69 >> AUTOMAKE_VERSION=1.16 >> CC=cc >> C_INCLUDE_PATH=/usr/local/include >> LIBRARY_PATH=/usr/local/lib > > I see you have changed the install instructions in the INSTALL file > (slapping them onto the Aug 14 commit without mentioning it or > reflecting it in the commit message). There is a few problems: > > 1. > On some systems, in particular OpenBSD, the autoreconf insists > that 'libtool' is the GNU libtool (of course). So the requirement > to have autoconf, automake and autoconf-archive probably needs to > be augmented with GNU libtool; otherwise, Is there any other libtool? -- Måns Rullgård ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
On Aug 24 13:27:00, m...@mansr.com wrote: > Jan Stary writes: > > >> It all works fine on my VM with this environment and no configure options: > >> AUTOCONF_VERSION=2.69 > >> AUTOMAKE_VERSION=1.16 > >> CC=cc > >> C_INCLUDE_PATH=/usr/local/include > >> LIBRARY_PATH=/usr/local/lib > > > > I see you have changed the install instructions in the INSTALL file > > (slapping them onto the Aug 14 commit without mentioning it or > > reflecting it in the commit message). There is a few problems: > > > > 1. > > On some systems, in particular OpenBSD, the autoreconf insists > > that 'libtool' is the GNU libtool (of course). So the requirement > > to have autoconf, automake and autoconf-archive probably needs to > > be augmented with GNU libtool; otherwise, > > Is there any other libtool? http://cvsweb.openbsd.org/src/usr.bin/libtool/ http://man.openbsd.org/libtool Relative -L paths are put before absolute ones. This fixes many (but not all, unfortunately) issues when software links to libraries already installed instead of those just built because, for example, "-L/usr/local/lib" comes before "-L../libfoo". That seems to be precisely the problem we are seeing with the GNU libtool if SoX is already installed. ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
Jan Stary writes: > On Aug 24 13:27:00, m...@mansr.com wrote: >> Jan Stary writes: >> >> >> It all works fine on my VM with this environment and no configure options: >> >> AUTOCONF_VERSION=2.69 >> >> AUTOMAKE_VERSION=1.16 >> >> CC=cc >> >> C_INCLUDE_PATH=/usr/local/include >> >> LIBRARY_PATH=/usr/local/lib >> > >> > I see you have changed the install instructions in the INSTALL file >> > (slapping them onto the Aug 14 commit without mentioning it or >> > reflecting it in the commit message). There is a few problems: >> > >> > 1. >> > On some systems, in particular OpenBSD, the autoreconf insists >> > that 'libtool' is the GNU libtool (of course). So the requirement >> > to have autoconf, automake and autoconf-archive probably needs to >> > be augmented with GNU libtool; otherwise, >> >> Is there any other libtool? > > http://cvsweb.openbsd.org/src/usr.bin/libtool/ > http://man.openbsd.org/libtool > > Relative -L paths are put before absolute ones. > This fixes many (but not all, unfortunately) issues > when software links to libraries already installed > instead of those just built because, for example, > "-L/usr/local/lib" comes before "-L../libfoo". > > That seems to be precisely the problem we are seeing > with the GNU libtool if SoX is already installed. Why doesn't someone from OpenBSD get it fixed in GNU libtool? -- Måns Rullgård ___ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
Re: [SoX-devel] Build system cleanup
Jan Stary writes: > On Aug 24 13:19:36, m...@mansr.com wrote: >> Jan Stary writes: >> >> >> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng >> >> > [...] >> >> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng >> >> > [...] >> >> > >> >> > The first works, the second does not. >> >> > The only difference between the two is the place >> >> > where the extra -L/usr/local/lib gets added, >> >> > as described in the previous emails. >> > >> > And it seems libtool itself is the one who breaks it. >> > This is the failing line again: >> > >> > /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 -Wl,--as-needed -o sox sox.o >> > libsox.la -lm >> > >> > Notice the "-L/usr/local/lib -Wl,--as-needed". >> > The "-L/usr/local/lib" part comes from the configure arg: >> > >> > ./configure CC=cc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib >> > >> > The "-Wl,--as-needed" comes from >> > >> > $ grep as-needed configure.ac >> > AX_APPEND_LINK_FLAGS([-Wl,--as-needed]) >> > >> > That results in the following line in src/Makefile: >> > >> > LDFLAGS = -L/usr/local/lib -Wl,--as-needed >> > >> > and that's what is passed in the above command line. Now, libtool >> > apparently preprocesses the line into something else; in particular, >> > it reorders the options. The very next command is: >> > >> > libtool: link: cc -g -O2 -fstack-protector-strong -Wall >> > -Wmissing-prototypes -Wstrict-prototypes -Wl,--as-needed -o .libs/sox >> > sox.o -L/usr/local/lib -L./.libs -lsox -lpng -lltdl -lao -lgsm -lmad >> > -lmp3lame -ltwolame -lid3tag -lz -lopusfile -lopus -lsndio -lvorbisfile >> > -lwavpack -lcrypto -lsndfile -lFLAC -lvorbisenc -lvorbis -logg -lm >> > -Wl,-rpath,/usr/local/lib >> > >> > Notice where the -L/usr/local/lib has been moved. >> > As described previously, if it comes after -lsox >> > instead of before it, it links just fine. >> >> None of this has changed. The problem is that you have an old libsox in >> /usr/local/lib, and with that -L flag early in the command, it takes >> precedence over the just-built libsox, causing the link to fail. > > This seems to be the case - together with GNU libtool > putting that -L/usr/local/lib _before_ the -L./.libs > which would link with the "new" libsox. > > (And, indeed, > $ nm /usr/local/lib/libsox.so.4.0 | grep lsx_malloc > $ nm src/.libs/libsox.so.3.0 | grep lsx_malloc > 00042f60 T lsx_malloc > which was the actual unresolved symbol, among others). > > I can confirm that deleting the previous version of sox > (installed in /usr/local/ via the OpenBSD sox-14.4.2p5 port) > makes that problem go away; or, better put, masks the bug > by removing the condition under which is shows. Good, we're finally in agreement. >> This whole issue is unique to OpenBSD. > > Having a previous version installed while a new one > is being built is to be expected, right? Yes, and it works everywhere I've tested it except OpenBSD. > Searching for -lsox in the -L path is also perfectly normal. > As we now know, it is the order of the -L options > introduced by GNU libtool that breaks it. > > Your "clean" VM is a special case in that it does not > have a previous version installed (as opposed to my screwed up, > misconfigured machine). When you install the previous sox 14.4.2 > (pkg_add sox), does the > > ./configure CC=cc CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib > make V=1 > > build still work? I assume it will break. >> On Linux and FreeBSD the link command uses the full filename of libsox, >> so it isn't searched for in the -L locations. > > I didn't get to FreeBSD testing yet, but on NetBSD > (where the build fails in other interesting ways), it's > > libtool: link: gcc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes > -Wstrict-prototypes -fopenmp -Wl,--as-needed -o .libs/sox sox.o > ./.libs/libsox.so -L/usr/pkg/lib -lmagic /usr/pkg/lib/libFLAC.so > /usr/pkg/lib/libopusfile.so /usr/pkg/lib/libopus.so > /usr/pkg/lib/libvorbisenc.so /usr/pkg/lib/libvorbisfile.so > /usr/pkg/lib/libvorbis.so /usr/pkg/lib/libogg.so -lm -fopenmp -Wl,-rpath > -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib > > So even some of the external libraries are linked via absolute paths - > seems to be precisely those detected by pkg-config > (not sure what the point of pkg-config --libs is then); > the others (-lm -lmagic) are found in the -L path. > > The linking commands are not invented by Linux or FreeBSD or OpenBSD > - they are what libtool or ./configure (or whatever it is inside the > auto* maze) put into the actual Makefile(s). If I understand the idea > of autotools at all, the supposed position of libtool is > > "Yo, I know how any given system/linker links; > so I can issue the right linking commands > for this system/linker right here,
