Compile issue with configure_options

Hello,

I noticed a strange thing when the --disable-static option is passed to the configure_options in a recipe_type=configure

The PrepareProgram output:

checking whether to build static libraries... no

however the static library has been built. I wonder if ultimately all the options contained in the configure_options are not taken into account. I tried with my knowledge to find the source of the issue unfortunately without success.

My guess is that the program you’re building is simply not honoring the --disable-static flag from autoconf.

Hi lucasvr

This is what I thought when I first encountered this issue during the build of PCRE2 and here is the link of the bug report but it was not possible to reproduce it.

Would it be possible in this case that Arch distribution uses a hook which removes the static file in one way or another?

The thing is that “issue” hit a lot of programs, that why I find it abnormal.

Strange, it works for me:

$ sudo Compile pcre2
...
checking whether to build shared libraries... yes
checking whether to build static libraries... no
...

$ ls /Programs/PCRE2/10.35/lib 
libpcre2-16.so    libpcre2-16.so.0.10.0  libpcre2-32.so.0       libpcre2-8.so    libpcre2-8.so.0.10.0  libpcre2-posix.so.2      pkgconfig
libpcre2-16.so.0  libpcre2-32.so         libpcre2-32.so.0.10.0  libpcre2-8.so.0  libpcre2-posix.so     libpcre2-posix.so.2.0.3

Also, looking in the config.log generated by the configure script I confirm that the default settings (which includes --disable-static) have been used:

$ grep ./configure config.log | head -n1
./configure --prefix=/usr --sysconfdir=/System/Settings --localstatedir=/Data/Variable --mandir=/usr/share/man --libexecdir=/usr/lib/pcre2 --disable-static --enable-pcre2-16 --enable-pcre2-32

Well, so there is a problem on my side, that not good :slightly_frowning_face:

This is really weird. I did a fresh installation of Gobolinux 017 and I have the static built.

Looking in the config.log generated by the configure script the default settings (which includes --disable-static) have been used:

It’s just amazing! Any idea where I should start to debug this issue ?

EDIT:
Well, the first thing obviously was to run all the commands manually and you know what, the static librairies are not built.

So now the thing is clear that there is an issue with Compile, the question is where I should look, or how can I debug the build process during the use of Compile, or any others idea to fix that. :grinning:

EDIT:
In comparison this is what I get with Compile

PCRE2 builds static libs even if you disable them, this has been discovered and discussed before:
https://freenode.logbot.info/gobolinux/20200722#c4470822
https://freenode.logbot.info/gobolinux/20200722#c4472529

I suppose it is a bug in the PCRE2 build system.

As parranoidd mentioned in the irc logs, you could remove the static libs in a pre_install command.

This is not only a PCRE2 issue.
First as I shown before manually building PCRE2 doesn’t produce the static libs.

Now let’s take another library like libtheora built on a fresh Gobolinux 17 installation.

The recipe look like that
Libtheora-Recipe

The result after running Compile show that static libraries has been built:

The result after running a manual configuration and compilation show no static librairies:

1 Like

Well that’s bad.
Maybe it sounds dumb, but did you try adding “double quotes” around the configure options?

configure_options=(
        "--enable-shared"
        "--disable-static"
        "--disable-example"
)

This seems to be the way it’s descibed in the wiki Recipe Format Specification · gobolinux/Documentation Wiki · GitHub.

Just to be sure the arguments are getting parsed correctly.

Maybe it sounds dumb, but did you try adding “double quotes” around the configure options?

Still the same issue.

@yann-kaelig Do you think you could figure out clear and concise repro steps?

It seems weird that @lucasvr appeared to have different results.

EDIT: I also noticed occurences of this in the past but I cant explain myself why that would happen.
I mean it does honor the other configure options you set, right?

Recipes are parsed by Bash, so the quotes don’t matter there.

One step to narrow it down would be to check that the options are passed as expected to configure - an easy way to do that is just to run ps while it’s running and see what the reported command line is (and then try the same command line in the manual build and see what happens).

@mwh I am not sure how we are supposed to utilize ps? I’ve used ps -e -f in a separate terminal but I did not see the commands that Compile runs.

But I’ve looked into it further and I’ve noticed that autoconf options are being passed correctly:

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no

But then later on libtool seems to install static libs:

 /usr/bin/libtool --mode=install /System/Index/bin/install -c  libtheoradec.la /usr/lib/libtheoradec.la
libtool: install: /System/Index/bin/install -c .libs/libtheoradec.so.1.1.4 /usr/lib/libtheoradec.so.1.1.4
libtool: install: (cd /usr/lib && { ln -s -f libtheoradec.so.1.1.4 libtheoradec.so.1 || { rm -f libtheoradec.so.1 && ln -s libtheoradec.so.1.1.4 libtheoradec.so.1; }; })
libtool: install: (cd /usr/lib && { ln -s -f libtheoradec.so.1.1.4 libtheoradec.so || { rm -f libtheoradec.so && ln -s libtheoradec.so.1.1.4 libtheoradec.so; }; })
libtool: install: /System/Index/bin/install -c .libs/libtheoradec.lai /usr/lib/libtheoradec.la
libtool: install: /System/Index/bin/install -c .libs/libtheoradec.a /usr/lib/libtheoradec.a
libtool: install: chmod 644 /usr/lib/libtheoradec.a
libtool: install: ranlib /usr/lib/libtheoradec.a

Here is the full log View paste TQAA

I fixed the static-lib issue by removing this line from Compile software

But also I don’t understand why there is a check on LIBTOOL.

1 Like

Oh, I couldn’t have guessed that libtool was to blame. Good spot.

The thing with libtool is that it errors when libs are built against a given prefix but installed to a different directory. The libtool script we ship with Gobo comes with a workaround, so Compile is instructed to use that version of the script (unless the recipe explicitly sets $LIBTOOL, in which case we don’t override it).

A different approach perhaps would be to live-patch the libtool script, but that’s too error prone. Ideas are welcome.

Hello

You mean by that if we run ./configure --prefix=/Foo and make install prefix=/Foo/Bar ?

Thx

Yes, that’s correct. The Compile tool builds with ./configure --prefix=/usr and installs with make install prefix=/Programs/Foo/Version. If libtool is part of the build/install process then you’re pretty much guaranteed to see an installation failure like this one:

error: cannot install ‘$file’ to a directory not ending in $libdir

Please refer to this patch for the workaround we’re placing around libtool.

1 Like