I need to get a newer gcc properly installed on SunOS in user space.
I tried a lot of things already, also following some hints of a
kind person listening to this list (merci, Pierre), but to no avail so far.
The package available on the net is only installable by root.
Why are there not simply user-installable packages available for
the Sun Gnu software? Or why isn't there at least a tool to locally
unpack a Sun package?
Actually, I have been able to extract the gcc Sun package with a lot
of tricks and hassles using dd and cpio. With some additional tweaks
for PATH and library searching, I was even able to setup a usable gcc
from the package. But the software package I actually wanted to
compile with it (maildrop) still fails, probably due to lack of
proper installation of gcc, looking at the errors:
-------------------------------------------------------
source='maildirkeywords4.cpp' object='maildirkeywords4.lo' libtool=yes \
DEPDIR=.deps depmode=gcc /bin/bash ./../depcomp \
/bin/bash ./libtool --quiet --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I. -I/home/demsn702/include -g -O2 -Wall -c -o maildirkeywords4.lo maildirkeywords4.cpp
In file included from /org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/bits/postypes.h:46,
from /org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/iosfwd:50,
from /org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/bits/stl_algobase.h:70,
from /org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/bits/stl_tree.h:66,
from /org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/set:66,
from maildirkeywords.h:435,
from maildirkeywords4.cpp:9:
/org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/cwchar:166: error: `::vfwscanf' has not been declared
/org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/cwchar:170: error: `::vswscanf' has not been declared
/org/mdd/tmp/gcc/reloc/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/cwchar:174: error: `::vwscanf' has not been declared
-------------------------------------------------------
Then I was told:
> Why not simply taking the sources and compile?
Well, I tried this with gcc 4.0.2 and gcc 3.4.4 and both failed to compile.
With 4.0.2, the error is while compiling strstream.cc:
-------------------------------------------------------
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 136: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 137: error: missing ')'
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 137: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 152: error: statement syntax
...
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 1846: error: invalid number of operands
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 1846: error: statement syntax
/usr/ccs/bin/as: "/tmp/ccU3Mg9i.s", line 1848: error: unknown opcode "_ZT"
...
and lots more.
-------------------------------------------------------
Then I was told to use a newer version of "as".
I did this but I'm stuck with a really mind-boggling effect; gcc
refuses to use the new version of "as", no matter what I do.
It's still using /usr/ccs/bin/as and reporting the bug above.
I put the new version of "as" first in the PATH, of course.
Then reconfigured gcc. No change.
I took /usr/ccs/bin completely out of my path, so that make complained
about nm and ar, which I copied somewhere else into my path.
Then reconfigured gcc. No change.
I called make CC="gcc -B $HOME/bin". No change.
Then I compiled the affected file
sparc-sun-solaris2.8/libstdc++-v3/src/.libs/strstream.o
manually, manipulating the -B option, which actually worked.
Unfortunately, when trying to continue with make, the object file
was deleted again so it's stuck.
I explicitly modified the "AS = as" line in Makefile to point to the
newer "as" in my path. No change.
I tried to manipulate all those -B parameters in Makefile and in the
Makefile of the affected subdirectory. No change.
I'm really fed up with this configuration crap.
Why does make/gcc insist to invoke /usr/ccs/bin/as if I tell it not to?
And why does it delete the object file again after I had successfully
produced it manually?
Is this to harass users who dare to compile gcc themselves? I can
hardly believe what's going in there.
How can I get past this blocking point (and possibly further ones)?
Thank you for any useful hints and kind regards,
Thomas Wolff
