Problem with static linking

Problem with static linking

[Hendrik Muhs]

Hi,

I have a problem with static linking. Please look at the following example.

The main programm foo "dlopens" the shared library bar and calls the function 
in bar.

If I compile at least bar.c or foo.c not static:

gcc -o foo foo.c -ldl
gcc -shared -o bar.so bar.c

or 

gcc -static -o foo foo.c -ldl
gcc -shared -o bar.so bar.c

or 

gcc -o foo foo.c -ldl
gcc -shared -o bar.so bar.c -Wl,-static

it works. But if compile both static:

gcc -static -o foo foo.c -ldl
gcc -shared -o bar.so bar.c -Wl,-static

I get a segfault(in malloc):

hendrik@tux:~> ./foo
we are in bar
Segmentation fault

I tried it with different versions of gcc: 2.95.3, 3.0.3(both SuSE Linux 7.3) 
and 2.96(Redhat Linux 7.2)

the code:

//foo.c
#include <stdio.h>
#include <dlfcn.h>
int main (void)
{
  void *lib;
  int (*sym)(void);
  lib = dlopen("./bar.so", RTLD_NOW);
  if (!lib) {
        fputs (dlerror(), stderr);
        exit(1);
  }
  sym = dlsym(lib, "bar");
  (*sym)();
  dlclose(lib);

  return 0;
}

//bar.c
#include <stdlib.h>
#include <malloc.h>
int bar(void)
{
 char *buf;
 printf("we are in bar\n");
 buf = malloc(5);
 printf("return to foo\n");
 return 0;
}

Why does it segfaults?

Thanks in advance,

Hendrik

Problem with static linking

[Hendrik Muhs]

Hi,

I have a problem with static linking. Please look at the following example.

The main programm foo "dlopens" the shared library bar and calls the function 
in bar.

If I compile at least bar.c or foo.c not static:

gcc -o foo foo.c -ldl
gcc -shared -o bar.so bar.c

or 

gcc -static -o foo foo.c -ldl
gcc -shared -o bar.so bar.c

or 

gcc -o foo foo.c -ldl
gcc -shared -o bar.so bar.c -Wl,-static

it works. But if compile both static:

gcc -static -o foo foo.c -ldl
gcc -shared -o bar.so bar.c -Wl,-static

I get a segfault(in malloc):

hendrik@tux:~> ./foo
we are in bar
Segmentation fault

I tried it with different versions of gcc: 2.95.3, 3.0.3(both SuSE Linux 7.3) 
and 2.96(Redhat Linux 7.2)

the code:

//foo.c
#include <stdio.h>
#include <dlfcn.h>
int main (void)
{
  void *lib;
  int (*sym)(void);
  lib = dlopen("./bar.so", RTLD_NOW);
  if (!lib) {
        fputs (dlerror(), stderr);
        exit(1);
  }
  sym = dlsym(lib, "bar");
  (*sym)();
  dlclose(lib);

  return 0;
}

//bar.c
#include <stdlib.h>
#include <malloc.h>
int bar(void)
{
 char *buf;
 printf("we are in bar\n");
 buf = malloc(5);
 printf("return to foo\n");
 return 0;
}

Why does it segfaults?

Thanks in advance,

Hendrik

Re: Problem with static linking

[Robert A Nesius]

On Fri, 18 Jan 2002, Hendrik Muhs wrote:

> Hi,
>
> I have a problem with static linking. Please look at the following example.
>
> The main programm foo "dlopens" the shared library bar and calls the function
> in bar.
>
> If I compile at least bar.c or foo.c not static:
> ...
>
> it works. But if compile both static:
>
> ...
>
> I get a segfault(in malloc):
>
> hendrik@tux:~> ./foo
> we are in bar
> Segmentation fault
>
> Why does it segfaults?
>

Hi Hendrik,
Perhaps the problem is that when you compile both binaries
"statically" the binaries generated do not use address independent
memmory references?  That is, maybe in both binaries, the memory
references begin at the same point in memory, and your malloc
is stomping over part of your running code.

I'm wondering if using -fPIC to build your binaries would help.
I'm not 100% sure if -fPIC and 'static' binaries go together, but
this is the only thing I can think of.

-Rob

-- 
#include <sig.h>
------------------------------------------------------------------
Robert Nesius             rnesius@ichips.intel.com    503.712.2181
DPG Engineering Computing SW Applications Team

Re: Problem with static linking

[Hendrik Muhs]

> Hi Hendrik,
> Perhaps the problem is that when you compile both binaries
> "statically" the binaries generated do not use address independent
> memmory references?  That is, maybe in both binaries, the memory
> references begin at the same point in memory, and your malloc
> is stomping over part of your running code.
>
> I'm wondering if using -fPIC to build your binaries would help.
> I'm not 100% sure if -fPIC and 'static' binaries go together, but
> this is the only thing I can think of.

Hi Robert,

thank your for your answer. 

I also thought about PIC, unfortunately this segfaults, too.

In my Opinion the example code(and my real code) and the compiler options are 
OK. It should not fail.

Hendrik
-- 

Re: Problem with static linking

[Hendrik Muhs]

> Hi Hendrik,
> Perhaps the problem is that when you compile both binaries
> "statically" the binaries generated do not use address independent
> memmory references?  That is, maybe in both binaries, the memory
> references begin at the same point in memory, and your malloc
> is stomping over part of your running code.
>
> I'm wondering if using -fPIC to build your binaries would help.
> I'm not 100% sure if -fPIC and 'static' binaries go together, but
> this is the only thing I can think of.

Hi Robert,

thank your for your answer. 

I also thought about PIC, unfortunately this segfaults, too.

In my Opinion the example code(and my real code) and the compiler options are 
OK. It should not fail.

Hendrik
-- 

Re: Problem with static linking

[Zachary Turner]

On Wed, Jul 15, 2009 at 10:41 PM, Ian Lance Taylor<iant@google.com> wrote:
> Zachary Turner <divisortheory@gmail.com> writes:
>
>> The codebase is large, but is new to linux.  It was originally
>> developed on windows and then ported to linux.  It makes heavy use of
>> C++, STL, and boost and we'd like to (if possible) link *everything*
>> statically.  This means libc, libgcc, libstdc++, boost, libpthread,
>> etc.
>
> This message is not appropriate for the gcc@gcc.gnu.org mailing list.
> It would be appropriate for the gcc-help@gcc.gnu.org mailing list.
> Please take any followups to gcc-help.  Thanks.
>
> This is actually not a gcc issue.  This is a library issue.  On
> GNU/Linux, the library is glibc.  The glibc maintainers have decided
> that they do not want to support static linking (I personally disagree
> with this position).  They only support dynamically linking against
> libc.  Static linking sort of grudgingly works, but some things will
> fail.  For example, if your statically linked program does DNS lookups,
> it will generally fail on any system which is not running the precise
> version of glibc as the system on which it was built.
>
> My guess is that the problems you are encountering are problems
> statically linking with glibc.  You can certainly bring these up with
> the glibc maintainers--see http://sourceware.org/glibc .  However, they
> will ignore you with prejudice.
>
> You may want to consider using -Bstatic and -Bdynamic to statically link
> everything except glibc.
>
> Ian
>

Thanks for your response despite the fact that I apparently posted to
the wrong list.  However, one thing still bothers me.  In particular
that an out-of-the-box installation of gcc appears to produce bogus
executables on gnu linux and neither the documentation, the compiler,
nor the linker issue any kind of warnings stating that this might
happen (or has already happened). In other words, the -static linker
option, at least under its current implementation, appears to be
*incompatible* with g++ (and for that matter, gcc as well) on gnu
linux.  The documentation does state that the -static option behaves
differently depending on whether or not it's supported by the
platform.  It seems to be unsupported on this platform, so shouldn't
it simply either report an error that this option is unavailable, or
produce an executable that is "as static as possible" but at least
works?

For example,

> g++ -v -static test.cpp -o test

produces an unusable executable.

g++ -v test.cpp -o test -nodefaultlibs -Wl,-Bstatic -lstdc++ -lm -lgcc
-lgcc_eh -Wl,-Bdynamic -lc

seems to work correctly (I haven't tested it in our large codebase
yet, just a simple program that throws and catches an exception in
main).  Since the first command line can apparently *never* produce
correct results, could it be changed to have the same behavior as the
second command line on gnu-linux?

Re: Problem with static linking

[Ian Lance Taylor]

Zachary Turner <divisortheory@gmail.com> writes:

> Thanks for your response despite the fact that I apparently posted to
> the wrong list.  However, one thing still bothers me.  In particular
> that an out-of-the-box installation of gcc appears to produce bogus
> executables on gnu linux and neither the documentation, the compiler,
> nor the linker issue any kind of warnings stating that this might
> happen (or has already happened). In other words, the -static linker
> option, at least under its current implementation, appears to be
> *incompatible* with g++ (and for that matter, gcc as well) on gnu
> linux.  The documentation does state that the -static option behaves
> differently depending on whether or not it's supported by the
> platform.  It seems to be unsupported on this platform, so shouldn't
> it simply either report an error that this option is unavailable, or
> produce an executable that is "as static as possible" but at least
> works?
>
> For example,
>
>> g++ -v -static test.cpp -o test
>
> produces an unusable executable.
>
> g++ -v test.cpp -o test -nodefaultlibs -Wl,-Bstatic -lstdc++ -lm -lgcc
> -lgcc_eh -Wl,-Bdynamic -lc
>
> seems to work correctly (I haven't tested it in our large codebase
> yet, just a simple program that throws and catches an exception in
> main).  Since the first command line can apparently *never* produce
> correct results, could it be changed to have the same behavior as the
> second command line on gnu-linux?

When I try -static with g++ on a hello, world program on GNU/Linux, the
resulting program does work, in that it prints hello, world.  I haven't
tried running valgrind on it.  If you find that -static gives you a
completely unusable executable--one that doesn't work at all--then
something may be wrong.  I tried gcc 4.3.2 on Fedora Core 10 using glibc
2.9.3.

Given that -static does work with simple executables, and given that the
gcc driver does hardly anything with -static other than pass it to the
linker, I think that gcc is behaving reasonably.  It would be annoying
for it to give an error.

Ian

Re: Problem with static linking

[Zachary Turner]

On Thu, Jul 16, 2009 at 12:46 AM, Ian Lance Taylor<iant@google.com> wrote:
> Zachary Turner <divisortheory@gmail.com> writes:
>
>> Thanks for your response despite the fact that I apparently posted to
>> the wrong list.  However, one thing still bothers me.  In particular
>> that an out-of-the-box installation of gcc appears to produce bogus
>> executables on gnu linux and neither the documentation, the compiler,
>> nor the linker issue any kind of warnings stating that this might
>> happen (or has already happened). In other words, the -static linker
>> option, at least under its current implementation, appears to be
>> *incompatible* with g++ (and for that matter, gcc as well) on gnu
>> linux.  The documentation does state that the -static option behaves
>> differently depending on whether or not it's supported by the
>> platform.  It seems to be unsupported on this platform, so shouldn't
>> it simply either report an error that this option is unavailable, or
>> produce an executable that is "as static as possible" but at least
>> works?
>>
>> For example,
>>
>>> g++ -v -static test.cpp -o test
>>
>> produces an unusable executable.
>>
>> g++ -v test.cpp -o test -nodefaultlibs -Wl,-Bstatic -lstdc++ -lm -lgcc
>> -lgcc_eh -Wl,-Bdynamic -lc
>>
>> seems to work correctly (I haven't tested it in our large codebase
>> yet, just a simple program that throws and catches an exception in
>> main).  Since the first command line can apparently *never* produce
>> correct results, could it be changed to have the same behavior as the
>> second command line on gnu-linux?
>
> When I try -static with g++ on a hello, world program on GNU/Linux, the
> resulting program does work, in that it prints hello, world.  I haven't
> tried running valgrind on it.  If you find that -static gives you a
> completely unusable executable--one that doesn't work at all--then
> something may be wrong.  I tried gcc 4.3.2 on Fedora Core 10 using glibc
> 2.9.3.
>
> Given that -static does work with simple executables, and given that the
> gcc driver does hardly anything with -static other than pass it to the
> linker, I think that gcc is behaving reasonably.  It would be annoying
> for it to give an error.
>
> Ian
>

What happens if you run valgrind on your hello world executable?  My
hello world app works as well, but when I run valgrind on it I get
tons of errors.  The errors could possibly be harmless, but on the
other hand I feel like they are probably an indication of something
serious, because when I run a larger application built in this way the
program appears to work for a while, but later terminates in ways that
make absolutely no sense.  The errors are unexplainable enough that I
can only attribute them to linking/library/configuration problems, and
given that valgrind reports over 70,000 errors on that codebase, all
similar to the valgrind errors I'm seeing when I compile this empty
program with -static, I have to think it's related.

I've experienced this behavior with glibc 2.9 on both ubuntu and Cent
OS with GCC 4.2.4, 4.3.x, and 4.4.0.  I've also experienced this
behavior with gcc compiling .c files as well.  Empty main function,
gcc test.c -static -o test && valgrind ./test.  It's possible I'm
doing something wrong, but I can't imagine what.  I agree that having
-static give an error would be annoying.  But producing an incorrect
binary is pretty annoying too :(

Zach

Re: Problem with static linking

[Ian Lance Taylor]

Zachary Turner <divisortheory@gmail.com> writes:

> What happens if you run valgrind on your hello world executable?

I get 32 errors about dependencies on uninitialized variables, much as
you mentioned.

I took a look at the first several.  They were all tests of %gs:0xc,
which is the multiple_threads field in the TCB.  That field is in memory
allocated by sbrk, which is guaranteed to be zero.  So I think although
valgrind may be correctly reporting that the program did not set the
field, I think it is wrong in thinking that the value is not known.

Ian

Re: Problem with static linking

[Zachary Turner]

On Thu, Jul 16, 2009 at 2:07 AM, Ian Lance Taylor<iant@google.com> wrote:
> Zachary Turner <divisortheory@gmail.com> writes:
>
>> What happens if you run valgrind on your hello world executable?
>
> I get 32 errors about dependencies on uninitialized variables, much as
> you mentioned.
>
> I took a look at the first several.  They were all tests of %gs:0xc,
> which is the multiple_threads field in the TCB.  That field is in memory
> allocated by sbrk, which is guaranteed to be zero.  So I think although
> valgrind may be correctly reporting that the program did not set the
> field, I think it is wrong in thinking that the value is not known.
>
> Ian
>

Well at least I know I'm not going crazy and that it happens
everywhere apparently.  Although I'm not sure if that's comforting or
demoralizing since it means my program's erratic behavior may not
necessarily be related to the linking issue.  I guess the appropriate
place to raise the issue about all the brk errors would be the
valgrind list.  What about errors such as this?

==5645== 1 errors in context 43 of 69:
==5645== Conditional jump or move depends on uninitialised value(s)
==5645==    at 0x80D227C: strlen (in /home/zach/test)
==5645==    by 0x8105DD4: _dl_init_paths (in /home/zach/test)
==5645==    by 0x80E389B: _dl_non_dynamic_init (in /home/zach/test)
==5645==    by 0x80E4245: __libc_init_first (in /home/zach/test)
==5645==    by 0x80B3DDD: (below main) (in /home/zach/test)
==5645==  Uninitialised value was created by a stack allocation
==5645==    at 0x8105BEB: _dl_init_paths (in /home/zach/test)

There's no mention of brk anywhere here, do you know if this case is
still safe anyway?

Re: Problem with static linking

[Ian Lance Taylor]

Zachary Turner <divisortheory@gmail.com> writes:

> Well at least I know I'm not going crazy and that it happens
> everywhere apparently.  Although I'm not sure if that's comforting or
> demoralizing since it means my program's erratic behavior may not
> necessarily be related to the linking issue.  I guess the appropriate
> place to raise the issue about all the brk errors would be the
> valgrind list.  What about errors such as this?
>
> ==5645== 1 errors in context 43 of 69:
> ==5645== Conditional jump or move depends on uninitialised value(s)
> ==5645==    at 0x80D227C: strlen (in /home/zach/test)
> ==5645==    by 0x8105DD4: _dl_init_paths (in /home/zach/test)
> ==5645==    by 0x80E389B: _dl_non_dynamic_init (in /home/zach/test)
> ==5645==    by 0x80E4245: __libc_init_first (in /home/zach/test)
> ==5645==    by 0x80B3DDD: (below main) (in /home/zach/test)
> ==5645==  Uninitialised value was created by a stack allocation
> ==5645==    at 0x8105BEB: _dl_init_paths (in /home/zach/test)
>
> There's no mention of brk anywhere here, do you know if this case is
> still safe anyway?

At first glance this looks like a fairly standard valgrind issue.
strlen picks up a word at a time.  That is OK because it only does it on
word-aligned addresses, and it looks for a null byte from the start of
the loaded bytes.  So although it is a read of uninitialized memory, it
is not serious.

I don't know for sure that that is what is happening here--I don't see
this warning when I run.

Ian