static linkage...

[Pavel Roskin]

On Tue, 16 Dec 2003, Andreas Boerner wrote:

> > Debian unstable: glib 2.2.3, Autoconf 2.58.  I'm using Automake 1.8
> > installed in /usr/local.
>
> gentoo:
>
> autoconf: 2.13
> automake 1.7.5
> glib: 2.2.3
>
> these are the most up-to-date; gentoo doesn't provide newer versions; I
> guess they are considered to be unstable...

I understand you are not compiling from CVS, so having old Autoconf
shouldn't be a problem.  However, new Autoconf has better documentation.

> > > setting environment variable LDFLAGS to -Wl,-static
> >
> > It's better to set variable on the command line:
> > ./configure LDFLAGS="-Wl,-static"
> >
>
> I didn't know this; where is that documented? I searched the web for
> about half an hour but didn't find details on how to statically link mc.
> And doing it that way doesn't change anything. Why is that better?

It is documented in later versions of Autoconf.  Run "info autoconf.info"
and see section "Defining Variables".

Everything on the command line is always passed to configure if it's
rerun.  The environment variables are not preserved except some known
"influential" variables.  LDFLAGS is one of them, but generally the
command line arguments should be preferred for scripts generated by
Autoconf 2.50 and later versions.

> my output is identical!
>
> checking for pkg-config... /usr/bin/pkg-config
> checking for glib-2.0... yes
> checking GLIB_CFLAGS... -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> checking GLIB_LIBS... -lglib-2.0

I know why.  The configure script doesn't really try to link against glib.
It trusts whatever pkg-config returns.  That's the downside of using
pkg-config.  Autoconf was created partly because UNIX vendors were
shipping broken libraries.  pkg-config and corresponding Autoconf macros
was created in the assumption that "we'll do it right this time".  Now it
appears that libraries using pkg-config cannot be trusted either.  Gentoo
is following UNIX traditions :-)

You should report the bug to Gentoo.  They should have libglib-2.0.a to
allow static linking.

> the gentoo distribution does not provide the option of static linkage at
> all; so I had to download the sources by myself and build it manually
> without the package-support of gentoo.
>
> I guess the developer from gentoo who wrote the install script for mc
> did not knew about the way how to compile mc statically. Since there is
> no configure option for that it is hard to guess...

I think that's what you should expect.  I don't think a distribution
should allow too many choices to the user.  Distributions are about
making a standard set of packages.  But I'm not familiar with gentoo
packaging system to comment any further.

> > > some thread references were missing...
> > >
> > > was solved by specifying ./configure --without-x ??
> >
> > Actually, the error messages would be more interesting than the command
> > line.  I have no idea if those messages are related to static linking.
> >
> > I could not reproduce this problem.
> >
>
> I don't want to follow this path, since I made manual modifications.
> Maybe the tread_... references are contained in glib-2.0, but not in
> glib ?? Or, more probable, some X-libraries contain thread references,
> since the error does not occur with --without-x

I mean I don't want to disable X support for static linking without even
seeing the error messages.

> > > I suggest to be able to do:
> > >
> > > ./configure --static
> >
> > That would be equivalent to what you did initially:
> > ./configure LDFLAGS="-Wl,-static"
> >
> > Adding an option doesn't automatically solve any problems with the
> > functionality it stands for.
>
> Technically speaking, that is true. But I disagree anyway: If there
> would be such an option, it is more obvious for install script writers
> (of the distributions) to support this option. I think you could imagine
> thousand more flag settings, but who knows, which are senseful and is
> going to test them. Static linkage in contrast isn't that fancy.

I'm concerned about possible confusion.  Static linking is not something I
would recommend to the end users.

> My summary: A configure option --static is more user friendly; it is
> more likely to be tested and corrected, if it doesn't work.

I agree with that.  But I think most users don't need that.  There will be
confused users and there will be useless misdirected bugreports.

> last question: To who should I send a bug report? (I think, that if the
> gentoo distribution decides, that they do not want to support static
> linkage, then I should still be able to link it manually without getting
> errors. I think that the least thing to expect is, that everything that
> mc needs (to link statically), should be checked by the configure
> script, and be reported by an meaningful error message!)

You may want to discuss this situation with libtool and pkg-config
developers.  Either libtool should encode the release number (as set by
the "-release" option) into static libraries, or pkg-config should have
support for static libraries without version numbers.

Make sure to search the web first.  I'm sure it was discussed.

-- 
Regards,
Pavel Roskin