s6 v2.9.2.0 compiles only disabling execline

s6 v2.9.2.0 compiles only disabling execline

[Joshua Ismael Haase Hernández]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

I'm building s6 from source on latest git tags and it seems to fail because
it cannot link execline:

./configure --disable-execline; make # works

./configure; make # fails with message
exec gcc -o s6-ftrig-listen -pipe -Wall -std=c99 -fno-exceptions
-fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack
-ffunction-sections -fdata-sections -O2 -fomit-frame-pointer
-fno-stack-protector  -Wl,--sort-section=alignment -Wl,--sort-common
-Wl,--gc-sections src/pipe-tools/s6-ftrig-listen.o libs6.a.xyzzy -lexecline
-lskarnet
/home/linuxbrew/.linuxbrew/bin/ld: cannot find -lexecline
collect2: error: ld returned 1 exit status
make: *** [Makefile:138: s6-ftrig-listen] Error 1

Execline is installed and available.

$ ls /usr/lib/execline/
libexecline.a

Any clues about how to solve this?

Re: s6 v2.9.2.0 compiles only disabling execline

[Joshua Ismael Haase Hernández]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

I was able to compile the following versions:

skalibs v2.9.2.0
execline v2.6.0.0
s6 v2.9.1.0
s6-dns v2.3.2.0
s6-networking v2.3.1.0

They mostly coincided to the march anouncement except for s6 networking
which could not find s6-dns on version v2.3.1.2.

El mié., 7 de octubre de 2020 3:52 p. m., Joshua Ismael Haase Hernández <
hahj87@gmail.com> escribió:

> I'm building s6 from source on latest git tags and it seems to fail
> because it cannot link execline:
>
> ./configure --disable-execline; make # works
>
> ./configure; make # fails with message
> exec gcc -o s6-ftrig-listen -pipe -Wall -std=c99 -fno-exceptions
> -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack
> -ffunction-sections -fdata-sections -O2 -fomit-frame-pointer
> -fno-stack-protector  -Wl,--sort-section=alignment -Wl,--sort-common
> -Wl,--gc-sections src/pipe-tools/s6-ftrig-listen.o libs6.a.xyzzy -lexecline
> -lskarnet
> /home/linuxbrew/.linuxbrew/bin/ld: cannot find -lexecline
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:138: s6-ftrig-listen] Error 1
>
> Execline is installed and available.
>
> $ ls /usr/lib/execline/
> libexecline.a
>
> Any clues about how to solve this?
>

Re: s6 v2.9.2.0 compiles only disabling execline

[Laurent Bercot]

>I'm building s6 from source on latest git tags and it seems to fail because
>it cannot link execline:
>
>./configure --disable-execline; make # works
>
>./configure; make # fails with message
>exec gcc -o s6-ftrig-listen -pipe -Wall -std=c99 -fno-exceptions
>-fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack
>-ffunction-sections -fdata-sections -O2 -fomit-frame-pointer
>-fno-stack-protector  -Wl,--sort-section=alignment -Wl,--sort-common
>-Wl,--gc-sections src/pipe-tools/s6-ftrig-listen.o libs6.a.xyzzy -lexecline
>-lskarnet
>/home/linuxbrew/.linuxbrew/bin/ld: cannot find -lexecline
>collect2: error: ld returned 1 exit status
>make: *** [Makefile:138: s6-ftrig-listen] Error 1
>
>Execline is installed and available.
>
>$ ls /usr/lib/execline/
>libexecline.a
>
>Any clues about how to solve this?

  ./configure --with-lib=/usr/lib/execline

  Alternatively, build execline with --libdir=/usr/lib so the
static libraries can be found in the default linker path.

  Yeah, it's annoying. It's the result of an initial design decision that
was theoretically logical but that has brought nothing but headaches
since. I don't want to change the default libdir, but I will probably
have to do it at some point because a lot of users are bumping on this.

--
  Laurent

Re: s6 v2.9.2.0 compiles only disabling execline

[Joshua Ismael Haase Hernández]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

El mié., 7 de octubre de 2020 7:22 p. m., Laurent Bercot <
ska-supervision@skarnet.org> escribió:

> >Any clues about how to solve this?
>
>   ./configure --with-lib=/usr/lib/execline
>
>   Alternatively, build execline with --libdir=/usr/lib so the
> static libraries can be found in the default linker path.
>

Awesome, thank you Laurent!

I don't want to change the default libdir,


Which advantages does this design bring to the table?

but I will probably have to do it at some point because a lot of users are
> bumping on this.
>

Why do some versions can compile without changes and some can't?

>

Re: s6 v2.9.2.0 compiles only disabling execline

[Laurent Bercot]

[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]

>Which advantages does this design bring to the table?

  - Header files are execline/*.h, it's logical to put static library
files in execline/*.a

  - /lib and /usr/lib are places where the dynamic linker looks for
shared libraries. Despite sharing the name "library", static and shared
libraries are not at all the same kind of object, they're not used for
the same purpose (shared libraries are run-time, static libraries are
build-time), so they should not be put in the same places. It is a
design mistake of a linker to look for static libraries in /lib and
/usr/lib, and a historical mistake of FHS not to have specified a
different default place for static libraries.

  - /usr/lib/foobar is traditionally used to host other files that are
related to the foobar package, such as unexported executable files
("libexec") or other read-only data. It is a naturally appropriate place
to put static libraries from the foobar package.

  Using /usr/lib/foobar as the default place to put libfoobar.a was my
attempt to organize files more rationally than FHS does and ld
encourages, but unfortunately people don't read INSTALL files or
./configure --help carefully (:P) and they're surprised when things
deviate ever so slightly from the lemming herd of all the autoconf-using
software - you're neither the first one to have trouble with this, nor
the last one.

  I guess it's my bad for pushing policy instead of sticking to 
mechanism.
I'll change the default in future versions of skarnet.org packages.


>Why do some versions can compile without changes and some can't?

  It's not the case.
  If you previously managed to build skarnet.org software without
specifying --libdir=/usr/lib or --with-lib=/usr/lib/foobar, then
chances are you already had an old version of libfoobar.a installed in 
/usr/lib/foobar (and linked against it), or you specified
--disable-allstatic and linked against libfoobar.so (which is in /lib
or /usr/lib). In the latter case, your build is correct; but in the
former, it accidentally succeeded and you didn't use the version of
libfoobar that you were aiming for.

  Which is, to me, a much bigger problem than hitting a build-time error.
I don't know how many incorrect builds have accidentally passed and are
currently running out there; this is reason enough to change the 
default.

--
  Laurent