[Bug driver/17219] New: -static and -statig-libgcc aren't doing what they should.

[Bug driver/17219] New: -static and -statig-libgcc aren't doing what they should.

[gonnetp at inf dot ethz dot ch]

I installed gcc-3.4.1 in a non-standard location (/usr/local/gcc/gcc-3.4.1/) and
I am having trouble running g++ programs compiled with it. Since it seems to be
al linking bug, it's easy to reproduce.

Given the program test.cc

    #include <iostream>
    using namespace std;

    main()
    {
        cout << "Hello World!";
        return 0;
    }

When I compile it in the most safe possilbe mode

    /usr/local/gcc/gcc-3.4.1/bin/g++ -static-libgcc test.cc \
    -L/usr/local/gcc/gcc-3.4.1/lib

I already get problems compiling:

    ld32: WARNING 127: Two shared objects with the same soname,
    /usr/lib32/mips3/libm.so and /usr/lib32/libm.so, have been been linked.
    This is probably due to a missing -L specification. Ignoring the latter.

Which is kind of odd, since I only have one _static_ version of libm, which, in
my opinion, should not be used. The executeable itself then fails with

    f15 307> ./a.out 
    80302:./a.out: rld: Fatal Error: Cannot Successfully map soname
    'libstdc++.so.7' under any of the filenames 
/usr/lib32/libstdc++.so.7:/usr/lib32/internal/libstdc++.so.7:/lib32/libstdc++.so.7:/opt/lib32/libstdc++.so.7:/usr/lib32/libstdc++.so.7.7:/usr/lib32/internal/libstdc++.so.7.7:/lib32/libstdc++.so.7.7:/opt/lib32/libstdc++.so.7.7: 

I can avoid this by adding /usr/local/gcc/gcc-3.4.1/lib to my LD_LIBRARY_PATH,
but this defeats the purpose of using "-static-libgcc". Adding just "-static"
has the same non-effect.

If this is just a bug in my setup I would be more than glad to know where to
start looking... 

Many thanks,
Pedro

-- 
           Summary: -static and -statig-libgcc aren't doing what they
                    should.
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gonnetp at inf dot ethz dot ch
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug driver/17219] -static and -statig-libgcc aren't doing what they should.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-28 01:33 -------
-static-libgcc only does libgcc and not libstdc++, what is the output of -static, if that does not work 
then this would be a bug in your linker and not GCC at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug driver/17219] -static and -statig-libgcc aren't doing what they should.

[gonnetp at inf dot ethz dot ch]

------- Additional Comments From gonnetp at inf dot ethz dot ch  2004-08-30 17:21 -------
Subject: Re:  -static and -statig-libgcc aren't doing what
 they should.


As mentioned in the bug report, -static has the same non-effect... I 
re-compiled with -static and -v and got:

f15 186> /usr/local/gcc/gcc-3.4.1/bin/g++ -v -static
-L/usr/local/gcc/gcc-3.4.1/lib/ test.cc 
Reading specs from 
/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/specs 
Configured with: ./configure --prefix=/usr/local/gcc/gcc-3.4.1 Thread 
model: single gcc version 3.4.1
 /usr/local/gcc/gcc-3.4.1/libexec/gcc/mips-sgi-irix6.5/3.4.1/cc1plus
-quiet -v test.cc -quiet -dumpbase test.cc -auxbase test -version -o
/scratch/jaffe/ccZVMzui.s ignoring nonexistent directory
"/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/../../../../mips-sgi-irix6.5/include"
#include "..." search starts here: #include <...> search starts here:
 

/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/../../../../include/c++/3.4.1
 

/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/../../../../include/c++/3.4.1/mips-sgi-irix6.5
 

/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/../../../../include/c++/3.4.1/backward
 /usr/local/include
 /usr/local/gcc/gcc-3.4.1/include
 /usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/include
 /usr/include
End of search list. 
GNU C++ version 3.4.1 (mips-sgi-irix6.5)
       compiled by GNU C version 3.4.1. 
GGC heuristics: --param
ggc-min-expand=65 --param ggc-min-heapsize=65536
 /usr/bin/as -EB -O0 -g0 -nocpp -show -G 0 -w -n32 -mips3 -o
/scratch/jaffe/ccSsyC2X.o /scratch/jaffe/ccZVMzui.s
/usr/bin/../../usr/lib32/cmplrs/as -DEFAULT:abi=n32:isa=mips4:proc=r10k
-EB -O0 -g0 -nocpp -show -G 0 -w -n32 -mips3 -o /scratch/jaffe/ccSsyC2X.o
/scratch/jaffe/ccZVMzui.s /usr/lib32/cmplrs/asm -t5_ll_sc_bug -pic2 -elf
-EB -O0 -g0 -G0 -w -mips3 -n32 /scratch/jaffe/ccZVMzui.s -o
/scratch/jaffe/ccSsyC2X.o
/usr/local/gcc/gcc-3.4.1/libexec/gcc/mips-sgi-irix6.5/3.4.1/collect2
-call_shared -no_unresolved -init __do_global_ctors -fini
__do_global_dtors -_SYSTYPE_SVR4 -woff 131 -n32 /usr/lib32/mips3/crt1.o
/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/crtbegin.o
-L/usr/local/gcc/gcc-3.4.1/lib/
-L/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1 -L/usr/bin
-L/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/../../..  
/scratch/jaffe/ccSsyC2X.o -lstdc++ -lm -dont_warn_unused -lgcc -lgcc_eh
-warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lc
-warn_unused -dont_warn_unused -lgcc -lgcc_eh -warn_unused
/usr/local/gcc/gcc-3.4.1/lib/gcc/mips-sgi-irix6.5/3.4.1/crtend.o
/usr/lib32/mips3/crtn.o 
ld32: WARNING 127: Two shared objects with the
same soname, /usr/lib32/mips3/libm.so and /usr/lib32/libm.so, have been
been linked.  This is probably due to a missing -L specification. Ignoring
the latter. 
f15 187>

"collect2", which I assume then calls the linker, has an argument 
"-call_shared" and nothing along the lines of "static"... Could it be that 
g++ is calling the linker with the wrong arguments? Is there a way to 
specifically see which arguments are passed to the linker?

Cheers and many thanks,
Pedro




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-30 18:37 -------
this would be a problem in LINK_SPEC but I don't know for sure.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|driver                      |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[gonnetp at inf dot ethz dot ch]

------- Additional Comments From gonnetp at inf dot ethz dot ch  2004-08-30 18:45 -------
Subject: Re:  -static and -statig-libgcc aren't doing what
 they should.


I looked at the parameters for the linker and it has an option 
"-non_shared". When I passed this through g++ I get:

f15 201> /usr/local/gcc/gcc-3.4.1/bin/g++ -static -Xlinker -non_shared
-L/usr/local/gcc/gcc-3.4.1/lib/ test.cc 
ld32: ERROR 4 : Conflicting flag
setting: -non_shared
        -call_shared may conflict with -shared 
collect2: ld returned 2 exit status

Which means that gcc/g++ is forcing shared somewhere... Is there any way I 
can work around this?

Cheers and thanks,
Pedro




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-31 06:01 -------
This is definitelly a target bug and can be confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-31 06:01:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-09-01 04:40 -------
Subject: Re:  -static and -statig-libgcc aren't doing what
 they should.

gonnetp at inf dot ethz dot ch wrote:
> f15 201> /usr/local/gcc/gcc-3.4.1/bin/g++ -static -Xlinker -non_shared
> -L/usr/local/gcc/gcc-3.4.1/lib/ test.cc 

-Xlinker causes an option to be ignored for specs processing, so we 
can't make this work.  Instead of using "-Xlinker -non_shared", you have 
to use just plain "-non_shared".  If that doesn't work, then we have 
another problem.  It seems to work right for a cross compiler though.

>         -call_shared may conflict with -shared 

-shared wasn't actually specified anywhere.  This is just telling you 
that -call_shared conflicts with your "-shared" setting, which was 
specified as -non_shared.

This goes away if you stop using -Xlinker, as then gcc stops emitting 
the -call_shared option.

The lack of -static support is I think a historical problem.  The Irix6 
compilers/linkers didn't support it, so we didn't bother adding support 
for it to the irix6 target.  They had a different way of specifying this 
stuff.

Also, as far as I know, irix6 doesn't really support static linking 
anymore.  It has been a very long time since I last used irix6, but at 
that time, static linking was only supported for running the SPEC 
benchmarks, because they got a very small performance boost with static 
code.  It wasn't recommended for any other purpose, and some C library 
features may not work in staticly linked applications.

There is also the issue that Irix6 code is always PIC.  If you want 
actual static non-pic code, then you need another option, but I'd 
strongly recommend against trying that, as that is even less likely to work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-01 04:59 -------
If this is true then how can we support -static, this is just like on *-*-darwin where -static is not 
supported at all, well it is but only for a few things and mainly inside Apple only and Kext support but 
then again KEXT support is not in the FSF compiler at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-09-01 23:49 -------
Subject: Re:  -static and -statig-libgcc aren't doing what
 they should.

pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-01 04:59 -------
> If this is true then how can we support -static, this is just like on *-*-darwin where -static is not 
> supported at all, well it is but only for a few things and mainly inside Apple only and Kext support but 
> then again KEXT support is not in the FSF compiler at all.

I am not sure which part you are asking about.

We can't make -Xlinker -static work.  No one should expect that to work, 
as -Xlinker means pass an option directly to the linker without looking 
at it.  This can only work for options that require no specs processing. 
  Similarly, -Wl,-static.

For irix6, we can presumably make -static work by modifying various 
specs rules to emit appropriate irix compiler/assembler/linker options. 
  If you are asking me specifically whether this is possible, then I 
can't answer that, as I don't have access to an irix6 box.  If you are 
asking me theoretically whether this is possible, then I am answering yes.

However, I think most of the debate is moot, as it isn't advisable to do 
static linking on irix6 anyways.  I don't remember all the details why, 
but I think part of the problem is that they have multiple versions of 
libc/libm, and if you static link, you may end up with code that won't 
run on all machines.  They maybe are also doing the glibc trick of using 
dlopen to load alternative libraries at runtime, which does not work if 
you link statically.

As for the pic vs non-pic issue, I think if you want non-pic static code 
from gcc for irix6, then you may have to do an actual port, as I don't 
believe there is any code in there to support this.  You can still link 
pic code statically, you just won't get all of the benefits of using 
static code and static libraries.

If this is all too complicated, then just say "-static isn't supported 
for Irix6" and close the bug report.  I think this is a   reasonable 
enough answer.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[gonnetp at inf dot ethz dot ch]

------- Additional Comments From gonnetp at inf dot ethz dot ch  2004-09-02 20:07 -------
Subject: Re:  -static and -statig-libgcc aren't doing what
 they should.



On 1 Sep 2004, wilson at specifixinc dot com wrote:
> For irix6, we can presumably make -static work by modifying various 
> specs rules to emit appropriate irix compiler/assembler/linker options. 
>   If you are asking me specifically whether this is possible, then I 
> can't answer that, as I don't have access to an irix6 box.  If you are 
> asking me theoretically whether this is possible, then I am answering yes.

Looking forward to seeing thins fixed :)
 
> However, I think most of the debate is moot, as it isn't advisable to do 
> static linking on irix6 anyways.  I don't remember all the details why, 
> but I think part of the problem is that they have multiple versions of 
> libc/libm, and if you static link, you may end up with code that won't 
> run on all machines.  They maybe are also doing the glibc trick of using 
> dlopen to load alternative libraries at runtime, which does not work if 
> you link statically.

The multiple versions I have here are 64 and 32 bit versions, so whatever 
I link at compile time will be the right one. The problem is that I have 
to deploy a stand-alone application on a bunch of irix boxes that don't 
have a gcc > 3.0 installed...

> If this is all too complicated, then just say "-static isn't supported 
> for Irix6" and close the bug report.  I think this is a   reasonable 
> enough answer.

Please don't do that...

Cheers and thanks
Pedro




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219

[Bug target/17219] -static and -statig-libgcc aren't doing what they should.

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-09-02 21:26 -------
Subject: Re:  -static and -statig-libgcc aren't doing what
 they should.

gonnetp at inf dot ethz dot ch wrote:
> Looking forward to seeing thins fixed :)

It will probably only be fixed if you write a patch for it.

I'd like to repeat again that using static linking on Irix6 is not a 
good idea.

> The multiple versions I have here are 64 and 32 bit versions, so whatever 
> I link at compile time will be the right one. The problem is that I have 

You should also have mips3 and mip4 versions of the 32-bit libraries. 
If I remember right, there is no mips3 64-bit library.  The mips4 
libraries won't work on a mips3 machine.  The mips3 libraries should 
work on a mips4 machine.  If you have a mips4 machine, the mips3 
libraries might be optional ones that aren't installed on your machine. 
  But if you do a normal link, against the shared libraries, you don't 
have to worry about any of this stuff.  The right library will always 
loaded in regardless of which machine you compile on and which machine 
you run on.

> to deploy a stand-alone application on a bunch of irix boxes that don't 
> have a gcc > 3.0 installed...

The best solution for this problem is to use --disable-shared when 
configuring gcc.  You will then get only static libgcc and libstdc++ 
libraries.  You can then link normally, and get the static versions of 
gcc libraries and shared/dynamic versions of the system libraries, which 
is really what you want.

GCC defaults to -mips3, so these static libgcc and libstdc++ libraries 
should work everywhere.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17219