Mantis - gcc4g++
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4875 regular use block always 2011-12-03 09:26 2012-02-26 12:28
Reporter: pfelecan Platform:  
Assigned To: maciej OS:  
Priority: high OS Version:  
Status: closed Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0004875: GCC 4.6.2 C++ : dynamic link issue
Description: The minimal program:

int main() {}

compiles, links (g++ -o c c.cc) but doesn't run; the following error
message is reported:

        ld.so.1: c: fatal: libstdc++.so.6: open failed: No such file or
        directory

and ldd reports:
    libstdc++.so.6 => (file not found)
    libm.so.2 => /lib/libm.so.2
    libgcc_s.so.1 => (file not found)
    libc.so.1 => /lib/libc.so.1

$ type g++
g++ is /opt/csw/bin/g++

$ g++ --version
g++ (GCC) 4.6.2
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:
Issue History
Date Modified Username Field Change
2011-12-03 09:26 pfelecan New Issue
2011-12-03 11:29 maciej Status new => assigned
2011-12-03 11:29 maciej Assigned To => maciej
2011-12-04 17:47 pfelecan Note Added: 0009456
2011-12-04 19:33 pfelecan Note Edited: 0009456
2011-12-05 11:09 maciej Note Added: 0009458
2011-12-11 00:48 maciej Note Added: 0009463
2011-12-11 19:47 maciej Note Added: 0009474
2011-12-12 10:30 maciej Note Added: 0009475
2011-12-12 11:28 pfelecan Note Added: 0009476
2011-12-12 11:29 pfelecan Note Edited: 0009476
2011-12-28 18:42 maciej Note Added: 0009511
2011-12-28 18:42 maciej Status assigned => feedback
2012-02-26 12:28 maciej Note Added: 0009658
2012-02-26 12:28 maciej Status feedback => closed
2012-02-26 12:28 maciej Resolution open => fixed

Notes
(0009456)
pfelecan   
2011-12-04 17:47   
(edited on: 2011-12-04 19:33)
a temporary solution to this is:

gcc -dumpspecs > /opt/csw/lib/gcc/i386-pc-solaris2.10/4.6.2/specs

change the directive *link_arch from :

%{m64:%{G:-G} %{YP,*} %{R*} %{compat-bsd: %{!YP,*:%{p|pg:-Y P,/opt/csw/lib:/usr/ucblib/64:/usr/lib/libp/64:/lib/64:/usr/lib/64} %{!p:%{!pg:-Y P,/usr/ucblib/64:/lib:/usr/lib/64}}} -R /usr/ucblib/64} %{!compat-bsd: %{!YP,*:%{p|pg:-Y P,/usr/lib/libp/64:/lib/64:/usr/lib/64} %{!p:%{!pg:-Y P,/lib/64:/usr/lib/64}}}}}%{!m64:%{G:-G} %{YP,*} %{R*} %{compat-bsd: %{!YP,*:%{p|pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib} %{!p:%{!pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib:%R/usr/lib}}} -R %R/usr/ucblib} %{!compat-bsd: %{!YP,*:%{p|pg:-Y P,%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib} %{!p:%{!pg:-Y P,%R/usr/ccs/lib:%R/usr/lib}}}}}

to :

%{m64:%{G:-G} %{YP,*} %{R*} -R /opt/csw/lib %{compat-bsd: %{!YP,*:%{p|pg:-Y P,/opt/csw/lib:/usr/ucblib/64:/usr/lib/libp/64:/lib/64:/usr/lib/64} %{!p:%{!pg:-Y P,/usr/ucblib/64:/lib:/usr/lib/64}}} -R /usr/ucblib/64} %{!compat-bsd: %{!YP,*:%{p|pg:-Y P,/usr/lib/libp/64:/lib/64:/usr/lib/64} %{!p:%{!pg:-Y P,/lib/64:/usr/lib/64}}}}}%{!m64:%{G:-G} %{YP,*} %{R*} -R /opt/csw/lib %{compat-bsd: %{!YP,*:%{p|pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib} %{!p:%{!pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib:%R/usr/lib}}} -R %R/usr/ucblib} %{!compat-bsd: %{!YP,*:%{p|pg:-Y P,%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib} %{!p:%{!pg:-Y P,%R/usr/ccs/lib:%R/usr/lib}}}}}

Note that this is not complete and specific to the Intel architecture.

To complete, you must manage 32 and 64 bit, profiling and debugging.

For the SPARC architecture the file's path is slightly different.
(0009458)
maciej   
2011-12-05 11:09   
At the moment, I'm still working on the ada build. I'll complete this, push the new packages to unstable, and then address this issue.

Peter, if you have any free time on your hands, you could look at the gcc4 recipe and see if you can write a patch for it.

https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ [^]

Maciej
(0009463)
maciej   
2011-12-11 00:48   
I found a relatively straightforward patch and applied it. The buildfarm is now building a new set of packages.
(0009474)
maciej   
2011-12-11 19:47   
No, this doesn't work the way I think it worked, and I don't understand what I'm doing. I need to do more research first.
(0009475)
maciej   
2011-12-12 10:30   
I started z thread on gcc-help, to see what the gcc developers say.

http://gcc.gnu.org/ml/gcc-help/2011-12/msg00100.html [^]

Their first answer for Solaris is "use crle". What do we say to that?
(0009476)
pfelecan   
2011-12-12 11:28   
(edited on: 2011-12-12 11:29)
There are at least 3 solutions for this issue:

1. use crle (I don't favor this); a postinstall script of gcc3core can do this

2. use a specs file supplied with the gcc4core package, similar to what I documented in an previous note (this is the easiest)

3. change the definition of the relevant values as documented in the gcc internals info file and for which I published the references on the maintainers list (this is the most elegant); BTW, I thought that you have done something approaching in the "straightforward patch".
(0009511)
maciej   
2011-12-28 18:42   
The updated packages are out for testing.

http://buildfarm.opencsw.org/experimental.html#gcc-4.6 [^]
(0009658)
maciej   
2012-02-26 12:28   
We now ship a custom spec file which fixes the problem. As a side effect, we add -R/opt/csw/lib or -R/opt/csw/lib/64 to all binaries.