Bug 690671 - missing libstdc++ not detected by autogen.sh
Summary: missing libstdc++ not detected by autogen.sh
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Config/Install (show other bugs)
Version: master
Hardware: Sun Solaris
: P4 normal
Assignee: Marcos H. Woehrmann
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-30 11:26 UTC by Marcos H. Woehrmann
Modified: 2010-05-18 09:28 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
Makefile (24.81 KB, text/plain)
2009-07-31 11:05 UTC, Marcos H. Woehrmann
Details
config.log (70.91 KB, text/plain)
2009-07-31 11:05 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2009-07-30 11:26:12 UTC
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
Comment 1 Ralph Giles 2009-07-30 14:25:00 UTC
Interesting. I wonder how mkromfs is getting linked into libstdc++. Can you
attach your Makefile and config.log?
Comment 2 Marcos H. Woehrmann 2009-07-31 11:05:01 UTC
Created attachment 5261 [details]
Makefile
Comment 3 Marcos H. Woehrmann 2009-07-31 11:05:21 UTC
Created attachment 5262 [details]
config.log
Comment 4 Marcos H. Woehrmann 2009-07-31 11:40:08 UTC
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).
Comment 5 Hin-Tak Leung 2010-05-02 03:12:57 UTC
Grabbing a Ralph's bugs.
Comment 6 Chris Liddell (chrisl) 2010-05-17 10:39:07 UTC
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++.
Comment 7 Chris Liddell (chrisl) 2010-05-17 10:42:16 UTC
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.
Comment 8 Chris Liddell (chrisl) 2010-05-18 09:28:29 UTC
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.