2011/12/3 Peter FELECAN <[email protected]>:
> "Maciej (Matchek) Bliziński" <[email protected]> writes:
>
>> 2011/12/2 Peter FELECAN <[email protected]>:
>>> 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
>>>
>>> If reporting this in Mantis or in private is preferred, I'll do it.
>>
>> Yes, please do. It's good for tracking progress.
>
> I'll do.
>
>> This behavior is known, it has always been like this. Before I
>> relocated the shared libraries, it was more obvious what to do,
>> because libstdc++ was in a nonstandard location (outside
>> /opt/csw/lib), and you had to add -R/opt/csw/gcc4/lib. Right now, the
>> library is in a standard location (/opt/csw/lib), but gcc won't add it
>> to the runpath by default.
>
> This was never an issue with gcc3 or gcc4 before.
It doesn't look like a regression to me. Not from gcc-4.3.3, anyway.
Please test with gcc-4.3.3 on the current* hosts.
maciej@current10x [current10x]:~/src/tmp $ echo "int main() {}" > test.cc
maciej@current10x [current10x]:~/src/tmp $ /opt/csw/gcc4/bin/g++ test.cc -o test
maciej@current10x [current10x]:~/src/tmp $ ./test
ld.so.1: test: fatal: libstdc++.so.6: open failed: No such file or directory
Killed
maciej@current10x [current10x]:~/src/tmp $ ldd test
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
maciej@current10x [current10x]:~/src/tmp $ /opt/csw/gcc4/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4
--exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib
--enable-libada --enable-libssp --enable-objc-gc
--enable-threads=posix --enable-stage1-languages=c
--enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)
maciej@current10x [current10x]:~/src/tmp $ /usr/sbin/pkgchk -l -p
/opt/csw/gcc4/bin/g++
NOTE: Couldn't lock the package database.
Pathname: /opt/csw/gcc4/bin/g++
Type: linked file
Source of link: /opt/csw/bin/isaexec
Referenced by the following packages:
CSWgcc4g++
Current status: installed
maciej@current10x [current10x]:~/src/tmp $ pkginfo -l CSWgcc4g++
PKGINST: CSWgcc4g++
NAME: gcc4g++ - GNU C++ Compiler
CATEGORY: application
ARCH: i386
VERSION: 4.3.3,REV=2009.05.07
BASEDIR: /
VENDOR: http://mirrors.kernel.org/gnu/gcc//gcc-4.3.3/ packaged
for CSW by Mike Watters
PSTAMP: mwatters@build8x-20090507210353
INSTDATE: Dec 08 2009 15:00
HOTLINE: http://www.opencsw.org/bugtrack/
EMAIL: [email protected]
STATUS: completely installed
FILES: 755 installed pathnames
14 shared pathnames
2 linked files
61 directories
14 executables
220021 blocks used (approx)
You are right that gcc3 uses custom specs and adds the runpath by default.
maciej@current10x [current10x]:~/src/tmp $ rm test
maciej@current10x [current10x]:~/src/tmp $ /opt/csw/gcc3/bin/g++ -o test test.cc
maciej@current10x [current10x]:~/src/tmp $ /usr/ccs/bin/dump -Lv test
| grep RPATH
[7] RPATH /opt/csw/lib
maciej@current10x [current10x]:~/src/tmp $ /opt/csw/gcc3/bin/g++ -v
Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.6/specs
Configured with: ../sources/gcc-3.4.6/configure --prefix=/opt/csw/gcc3
--with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-shared --enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib
--enable-languages=all
Thread model: posix
gcc version 3.4.6
Do we have the build recipe for gcc-3.4.6?
>> I'm not sure whether it's a good or a bad thing.
>>
>> There's a way to make gcc always add /opt/csw/lib to the runpath.
>>
>> One thing to do would be making sure that we can add a path that
>> precedes /opt/csw/lib, otherwise it would be impossible to get out of
>> problems such as the one with libnet.
>>
>> This was discussed some time ago on gcc-help. It's very easy to do it
>> wrong. For example, if you compile with -m64, then you need to add
>> -R/opt/csw/lib/64, and not -R/opt/csw/lib, and it has to be somehow
>> expressed in the patch for the gcc sources.
>
> This is managed by the specification file which support conditionals.
Are you already familiar with this file? For example, do you know the syntax?
Maciej
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
