0004875: GCC 4.6.2 C++ : dynamic link issue

(0009456)
pfelecan (developer)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
2011-12-28 18:42

The updated packages are out for testing.

http://buildfarm.opencsw.org/experimental.html#gcc-4.6 [^]

(0009658)
maciej (reporter)
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.

Notes
(0009456) pfelecan (developer) 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 (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 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 (developer) 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 (reporter) 2011-12-28 18:42	The updated packages are out for testing. http://buildfarm.opencsw.org/experimental.html#gcc-4.6 [^]

(0009658) maciej (reporter) 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.

Relationships

OpenCSW Bug Tracker