On Solaris an svn checkout of the current ghostscript (r9906) followed by "./autogen.sh ; make" results in an error: . . . gcc -DHAVE_MKSTEMP -DHAVE_HYPOT -DHAVE_FILE64 -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG - O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite- strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common - DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -I./psi -I./obj -I./obj -I./base -o ./obj/iconfig.o -c ./obj/iconfig.c gcc -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite- strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common - DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -O2 -Wall -Wstrict-prototypes - Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing - Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H - DGX_COLOR_INDEX_TYPE="unsigned long long" -I./base -I./obj/ -Izlib ./base/mkromfs.c -o ./obj/mkromfs ./obj/compress.o ./obj/deflate.o ./obj/zutil.o ./obj/adler32.o ./obj/crc32.o ./obj/trees.o ./obj/gscdefs.o ./obj/gsmisc.o ./obj/gpmisc.o ./obj/gslibctx.o ./obj/gp_getnv.o ./obj/gp_unix.o ./obj/gp_unifs.o ./obj/gp_unifn.o ./obj/gp_stdia.o ./obj/gsutil.o -lm -ldl -lm - lstdc++ -lfontconfig ./obj/mkromfs -o ./obj/gsromfs1.c \ -X .svn -X CVS \ \ -c -P ./lib/../Resource/ -d Resource/ CIDFont/ CMap/ ColorSpace/ Decoding/ Encoding/ Font/ IdiomSet/ Init/ ProcSet/ SubstCID/ -d lib/ -P ./lib/ ld.so.1: mkromfs: fatal: libstdc++.so.6: open failed: No such file or directory make: *** [obj/gsromfs1.c] Killed
Interesting. I wonder how mkromfs is getting linked into libstdc++. Can you attach your Makefile and config.log?
Created attachment 5261 [details] Makefile
Created attachment 5262 [details] config.log
The original error report comes from a Solaris install on a SPARC machine. I tried a fresh install of Solaris 10 x86 on a VMWare virtual machine and Ghostscript built cleanly. On the Solaris x86 install libstdc++.so is located in /usr/sfw/lib; it's also there on the SPARC machine but for some reason the compiler doesn't look in that directory (gcc is located in /usr/sfw/bin and my path on both machines includes that directory, but neither machine has a setting for the lib directories).
Grabbing a Ralph's bugs.
This is system configuration problem with the default Solaris installation. It is setup to allow gcc (with the Sun linker) to link executables against the shared libstdc++ (and other libs in there) in /usr/sfw/lib but the dynamic linker search path does not include that path. It is not a problem with autconf or our use of autoconf - the configure script correctly decides that the linker can create an executable linked to libstdc++.so - autoconf is not intended to check the configuration of the run-time linker. I would think that the correct course of action is to report this to the freeware Solaris tools maintainers at Sun. There are two solutions. If you have superuser privileges on the system, you can permanently update the run-time/dynamic linker search path with: crle -u -l /usr/sfw/lib The "-u" is /vital/ is it updates/appends to, rather than overwrites the default library search path. If you can't get superuser rights, setting: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/sfw/lib This needs to be set for every shell you spawn (so best done in .profile, or whatever) because the gs executable itself is also linked against libstdc++.
assigning back to Marcos for his consideration of the comment above.... if you feel strongly we need to do more, reopen and reassign to me.
Note: this is effectively "resolved" for the /default/ build by the changes for bug 691313 which removes the only user of stdc++ in the build (the IBM Omni driver). If the "--with-omni" option is given to configure, the problem recurs.