Trouble untar-ing gcc, unknown filetype

[Victor Semaska_3]

Greetings,

I need to install the gcc compiler with g++ on my Tru64 V5.1B PK5 system. I went to the GNU site and downloaded the 4.0.0 (stable) version. When I tried to untar it I get numerous lines of the following:

tar: ././@LongLink : Unknown filetype

I copied the tar file to my RedHat Linux system and it untar'd fine. Anyone know why this is and what can I do?

Thanks,
Vic

[Ivan Ferreira]

GNU tar has support for more file types then Tru64 tar.

What type of file is @LongLink?

[Victor Semaska_3]

No idea what kind of longlink it is. Someone did suggest gtar and I've found that on the OSSC disk but it is a RPM package and there's no rpm utility on Tru64 that I can find. Haven't found where to get that yet.

Vic

[Steven Schweda]

Get a copy of GNU "tar", build that, and use
it to unpack the GCC kit.

> [...] RedHat Linux system and it untar'd fine.

Guess which "tar" that was.

[Steven Schweda]

http://www.gnu.org/software/tar/

ftp://alpha.gnu.org/gnu/tar/tar-1.15.91.tar.gz

Also, if you have NFS working between the
Linus system and the Tru64 system, you should
be able to use the Linux (GNU) "tar" to
unpack the GCC kit onto a Tru64 file system.

[Victor Semaska_3]

Do you have a link for that. I've been looking for gtar or GNU tar on GNU's web-site and can't find anything.

Vic

[Ivan Ferreira]

>>> Someone did suggest gtar and I've found that on the OSSC disk but it is a RPM package and there's no rpm utility on Tru64 that I can find. Haven't found where to get that yet.


The rpm command is also in the OSSC CD. you should install it first. It's installed in /usr/local/bin/rpm. RPM-init.sh I think is the name of the rpm command installer.

[Victor Semaska_3]

Was able to download and install GNU tar so I was able to untar the gcc and g++. Tried to ./configure and make but it fails with:

cc: Error: ./floatformat.c, line 319: In this statement, the libraries on this p
latform do not yet support compile-time evaluation of the constant expression "0
.0/0.0". (constfoldns)
dto = NAN;
--------------^
*** Exit 1
Stop.
*** Exit 1
Stop.

Does anyone know where I can download a Tru64 binary of gcc w/ g++ so I don't have to try to compile this thing?

Thanks,
Vic

[Steven Schweda]

I use this one:

urtx# gcc -v
Reading specs from /usr/local/lib/gcc/alpha-dec-osf5.1/3.4.5/specs
Configured with: /usr/local/gnu/gcc-3.4.5/configure
Thread model: posix
gcc version 3.4.5

I haven't tried any of the 4.x stuff yet.

Interestingly (to me, anyway), I also seem to
have a 3.4.6 kit (from March 2006) which
never got built. Apparently it needs a
better "yacc" than the (Tru64) one I have,
and I never tried to get past that problem.

As for the build problem with 4.0.0, have you
considered trying 4.0.3 or 4.1.1? Why choose
the version with, judging only by its number,
the greatest probability of having some new
problem?

http://gcc.gnu.org/

[Vladimir Fabecic]

Victor
Do what Ivan said.
Mount a CD, find script RPM-init.sh and do:
# sh RPM-init.sh
Then install RPM package:
# /usr/local/bin/rpm packagename.rpm

[Steven Schweda]

If you do continue trying to build the thing
(whichever version), don't be amazed if you
need to use GNU "make" instead of the native
"make".

As for GCC 3.4.6, installing Bison 2.3
seemed to get past the "yacc" problem, and
using GNU "make" seems to have gotten past
at least one "make" complaint. (It will be a
while before I know if it runs to a
satisfactory end, but what (else) could go
wrong?)

[Victor Semaska_3]

The web-site that I was at said that's the stable version. Anyway, I decided to try version 4.1.0 but got a different error.

WARNING: `makeinfo' is missing on your system. You should only need it if
you modified a `.texi' or `.texinfo' file, or any other file
indirectly affecting the aspect of the manual. The spurious
call might also be the consequence of using a buggy `make' (AIX,
DU, IRIX). You might want to install the `Texinfo' package or
the `GNU make' package. Grab either from any GNU archive site.
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.

Should I install the GNU make now, DU I assume means Digital Unix?

Vic

[Victor Semaska_3]

Steven,

You're right, it looks like it needs GNU make. I've downloaded that and compiled it. It's located in /usr/local/bin/make. How do I get the gcc compile to use that version instead of the default.

Sorry for the probably dumb question but I've never done software compiling under UNIX.

Vic

[Steven Schweda]

> The web-site that I was at said [...]

And that was? I tend to go to the source:

http://gcc.gnu.org/
http://gcc.gnu.org/gcc-4.1/


May 24, 2006

The GNU project and the GCC developers are pleased to announce the release of GCC 4.1.1.

This release is a bug-fix release, containing fixes for regressions in GCC 4.1.0 relative to previous releases of GCC.


So, again, why on Earth choose an x.y.0 kit
when x.y.1 is available?

> Should I install the GNU make now,

My experience suggests that you'll need GNU
"make":

urtx# make bootstrap-lean
[...]
Bootstrapping the compiler
Make: Makefile: Must be a separator on line 778. Stop.
*** Exit 1
Stop.

urtx# type make
make is /sbin/make

Using /usr/local/bin/make, it's bubbling
along as expected.


> DU I assume means Digital Unix?

Sounds plausible.

According to the 3.4.6 "configure" script, my
"makeinfo" is also missing or obsolete, but
that does not seem to be a show-stopping
problem.

http://www.gnu.org/software/texinfo/

The best part about GNUware is its uncanny
ability to require ever more GNUware.

[Steven Schweda]

Personally, I have:

urtx# pwd
/usr/local/bin

urtx# ls -l *make
lrwxrwxrwx 1 root system 4 Jan 27 2006 gmake -> make
-rwxr-xr-x 1 root system 569824 Jul 23 2004 make

The "configure" script doen't need it, so it
should be good enough to say

gmake bootstrap-lean

or:

/usr/local/bin/make bootstrap-lean

I assume that you're looking at:

http://gcc.gnu.org/install/

If not, you should be.


> [...] I've never done software compiling
> under UNIX.

Educational, isn't it?

[Victor Semaska_3]

Steven,

I don't remember which web-site I was looking at but it probably was an old one. To be honest I went with 4.1.0 instead of 4.1.1 because that version were bz2 files and I didn't want to go hunting around for a bzip2 utility for Tru64. Anyway I did and downloaded 4.1.1

Tried it again with GNU make and it still failed so I installed texinfo. Hasn't failed yet but it keeps going, and going, and going. I did stop it and try your 'gmake bootstrap-lean' after creating the gmake symlink. Got:

csudut1:/usr/local/bin> gmake bootstrap-lean
make: *** No rule to make target `bootstrap-lean'. Stop.

So, started from scratch again with gcc and the make is still going. I'll leave it overnight if need be.

Yes I have been looking at http://gcc.gnu.org/install but again since I normally don't do this type of thing a lot of it doesn't mean anything to me.

Hopefully, this GNU make will work and I'll be done with it.

Vic

[Steven Schweda]

My 3.4.6 build is still cooking on the
500MHz XP1000, too. It does take a while.

You really should have a bzip2. It's popular
these days:

http://www.bzip.org/

or, for VMS:

http://antinode.org/dec/sw/bzip2.html

No doubt you could do that while waiting for
GCC to finish.

> csudut1:/usr/local/bin> gmake bootstrap-lean

You were in /usr/local/bin? No wonder.

The official procedure (simplified) is to
unpack the kit somewhere (like
/usr/local/gnu/gcc-3.4.6), make an empty
directory somewhere else for the generated
files (like /usr/local/gnu/gcc-3.4.6_obj),
"cd" into this directory, do the "configure"
(like "/usr/local/gnu/gcc-3.4.6/configure"),
then do the "make" in the same place (like
"gmake bootstrap-lean"), and, eventually,
perhaps, "gmake install".

http://gcc.gnu.org/install/configure.html

> [...] a lot of it doesn't mean anything to me.

You need to skip over most of the stuff, like
cross-compiling, and so on. Supposedly, you
can limit the languages, too (to save some
time and effort), but I had enough trouble
with that once that I now just let it build
everything it knows how to do, and hope that
I'll live long enough to see the end.

[Victor Semaska_3]

Well I used the GNU make which ran a lot longer and generated a lot more output but in the end it failed with:

../../.././libstdc++-v3/src/debug.cc:640: warning: deprecated conversion from string constant to 'char*''
../../.././libstdc++-v3/src/debug.cc:640: warning: deprecated conversion from string constant to 'char*''
../../.././libstdc++-v3/src/debug.cc:641: warning: deprecated conversion from string constant to 'char*''
../../.././libstdc++-v3/src/debug.cc:641: warning: deprecated conversion from string constant to 'char*''
make[4]: *** [debug.lo] Error 1
make[4]: Leaving directory `/cluster/members/member0/tmp/gcc-4.1.1/alphaev67-dec-osf5.1b/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/cluster/members/member0/tmp/gcc-4.1.1/alphaev67-dec-osf5.1b/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/cluster/members/member0/tmp/gcc-4.1.1/alphaev67-dec-osf5.1b/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/cluster/members/member0/tmp/gcc-4.1.1'
make: *** [all] Error 2

Looking back at the output from ./configure there was the message:
The following languages will be built: c,c++,java,objc
*** This configuration is not supported in the following subdirectories:
target-libmudflap target-libada gnattools target-libgfortran
(Any other directories should still work fine.)
Which I assume is OK.

Then I noticed there's a config.log file (again I'm new to this). I found this:
configure:2177: checking how to compare bootstrapped objects
configure:2275: checking for correct version of gmp.h
configure:2288: cc -c -g conftest.c 1>&5
cc: Severe: configure, line 2278: Cannot find file "gmp.h" specified in #include directive. (noinclfilef)
#include "gmp.h"
-^
configure: failed program was:
#line 2277 "configure"
#include "confdefs.h"
#include "gmp.h"
int main() {

#if __GNU_MP_VERSION < 3
choke me
#endif

; return 0; }

Any help with this will be appreciated.

Vic

[Steven Schweda]

My GCC 3.4.6 build eventually ran to (a
happy) completion. Assuming that it's not
all your fault for some reason (like not
following instructions), unless you're wedded
to 4.x for some reason, you might consider
that one.

Otherwise, as this seems to happen in the
C++ run-time stuff, if you don't need C++,
you might try starting fresh, and restricting
the languages to C in your "configure"
("--enable-languages=lang1,lang2,...")
That'd probably save some time, too.

Or you could try to get some of that free
support which some people tell me is so easy
to find for free software.

[Victor Semaska_3]

Well I tried 3.4.6 because the appl. that needs gcc says it'll work with gcc 3.x but that failed as well:

cc: Warning: f/bad.c, line 497: In this statement, the referenced type of the pointer value "s" is "const unsigned char", which is n
ot compatible with "const char" because they differ by signed/unsigned attribute. (ptrmismatch1)
bufi = ffebad_bufputs_ (buf, bufi, s);
-------------------------------------------------------^
make[1]: *** [f/bad.o] Error 1
make[1]: Leaving directory `/cluster/members/member0/tmp/gcc-3.4.6/gcc'
make: *** [all-gcc] Error 2

Time to give up and tell the user that I couldn't install the appl and look for another solution of which there are a few.

Thanks to everyone for their help.

Vic

[Steven Schweda]

Depending on your endurance, there may be a
couple more possibilities.

As I already had an older GCC C compiler
available, my recent GCC 3.4.6 build used
that one, so that probably helped in my case.
As "ptrmismatch" and "ptrmismatch1" seem (in
my experience) to be among the most common
complaints spewed by DEC/Compaq/HP C (on both
VMS and Tru64) when they are used on the
typical piece of (GNU-compatible) free
software, I can't say that I'm amazed by this
one.

I haven't tried it (lately?), but it should
be possible to go back to the beginning,
define an environment variable "CC" to be a
"cc -whatever" command which will disable
those warnings, and then re-run the
"configure" script, and take another whack at
it. (I'd fill in the details, but my Tru64
system is down now, and I don't have a Tru64
C guide handy. On VMS, it's "/WARNINGS =
(DISABLE=(ptrmismatch, ptrmismatch1))".
It's probably vaguely similar on Tru64.)

The code which triggers these complaints is
almost always harmless, so it's a pretty safe
work-around.

Alternatively, if you're really desperate, I
could probably box up my gcc-3.4.6_obj
directory, and leave it on my FTP/HTTP server
for a while. Send e-mail to
"sms@antinode-org" (more or less) to start
that option. It won't be small, of course,
but bzip2 compression is ok, right?

Of course, it's your life, and you're welcome
to reclaim whatever's left of it at any time.

[Steven Schweda]

For fun -- I'm easily entertained -- I tried
building GCC 3.4.6 starting with "cc" instead
of "gcc", and it seemed to work fine. The
sequence was:

mkdir gcc-3.4.6_obj2
cd gcc-3.4.6_obj2
CC=cc ../gcc-3.4.6/configure
gmake bootstrap-lean

It seemed to be using "cc" in the early
stage, as expected, so I'm rather at a loss
to explain a failure in this situation.
Perhaps your prayers have been directed at
the wrong deity.

Around here:

urtx# sizer -v
Compaq Tru64 UNIX V5.1B (Rev. 2650); Sat Jan 28 11:47:04 CST 2006

urtx# cc -V
Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver

urtx# $SHELL --version
GNU bash, version 3.1.1(1)-release (alpha-dec-osf5.1)
Copyright (C) 2005 Free Software Foundation, Inc.

[Steven Schweda]

And the magic C compiler option appears to be:

-msg_disable=ptrmismatch,ptrmismatch1

but I haven't actually tried it.

[Victor Semaska_3]

Steven,

Thanks for hanging in there. First I installed bash so as to have a similar environment, I was using ksh. I followed your steps and got the same error. I tried to use the -msg_disable option but it didn't work. Maybe it's the syntax.

bash-3.00# CC=cc ../gcc-3.4.6/configure -msg_disable=ptrmismatch,ptrmismatch1
configure: error: -msg_disable=ptrmismatch,ptrmismatch1: invalid option; use --help to show usage

bash-3.00# sizer -v
Compaq Tru64 UNIX V5.1B (Rev. 2650); Wed Mar 8 14:45:28 EST 2006

bash-3.00# cc -V
Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-003 (sys) cc Driver

bash-3.00# bash --version
GNU bash, version 3.00.0(1)-release (alphaev67-dec-osf5.1)
Copyright (C) 2004 Free Software Foundation, Inc.

Vic

[Victor Semaska_3]

Figured out the options problem, had to:
$ CFLAGS="-msg_disable ptrmismatch,ptrmismatch1"
$ export CFLAGS

Then do:
$ CC=cc ../gcc-3.4.6/configure

But it still fails:
cc -msg_disable ptrmismatch,ptrmismatch1 -DIN_GCC -DHAVE_CONFIG_H -o cc1plus \
cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp
/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o
cp/optimize.o cp/mangle.o cp/cp-lang.o cp/name-lookup.o cp/cxx-pretty-print.o attribs.o c-common.o c-format.o c-pragma.o c-semantics
.o c-lex.o c-dump.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o main.o libbacke
nd.a libcpp.a ../libiberty/libiberty.a ../intl/libintl.a -liconv
cc -c -msg_disable ptrmismatch,ptrmismatch1 -DIN_GCC -DHAVE_CONFIG_H -I. -If -I../../gcc-3.4.6/gcc -I../../gcc-3.4.6/gcc/f
-I../../gcc-3.4.6/gcc/../include -I../intl ../../gcc-3.4.6/gcc/f/bad.c -o f/bad.o
cc: Error: ../../gcc-3.4.6/gcc/f/proj.h, line 37: #error "You have to use gcc 2.x to build g77." (errormessage)
#error "You have to use gcc 2.x to build g77."
--^
gmake[1]: *** [f/bad.o] Error 1
gmake[1]: Leaving directory `/cluster/members/member0/tmp/gcc-3.4.6_obj2/gcc'
gmake: *** [all-gcc] Error 2

Does this really mean I have to 1st build gcc v2.x 1st?

Vic