make gcc433 on hp-ux11.23ia64

[Steven Schweda]

> I try others installed gcc too.
> gcc4.2.3 and gcc4.3.1, and it was with same
> errors.

I don't know what you installed, or how you
installed it. All I know is that it appears
not to work properly.

> Do you have any evidence that this compiler
> works (properly)? I do not expect a working
> compiler to complain about system header
> files ("/usr/include/sys/_inttypes.h",
> "/usr/include/sys/types.h", ...).

Still waiting for an answer to that one.

> [...] and set some variable like SHLIB_PATH
> and LD_LIBRARY_PATH.

I believe that the GCC builders can figure
out what to do with these (if anything)
without your help. _With_ your help --
that's "help" -- , I don't know what will
happen. It's possible that if you specify
bad values for these variables, or if the C
compiler doesn't work for some other reason,
then the "configure" scripts will not be able
to compile and link any of their little test
programs. If that happens, the results might
look as bad as what you see.

> how I may don't "use line 130 here"?

With a working C compiler, the GCC builders
should be defining STDC_HEADERS, so you
shouldn't need to do anything.

> [...] and not install gmp\mpfr in shared
> folder(in "/usr/local")?

I assume that all those "-with-xxx" options
should let you put your stuff wherever you
wish. I did it the easy way, and let the
GCC builders find things in the usual places.

[Johannes Krackowizer]

Why don't you use the compiled packages from http://hpux.cs.utah.edu ? I used their site since the late 1990s to get up running tools that i used with linux on hpux 10.20 and now i use it to run the tools on hpux 11.31.

you can find your os versions gcc under this link:

http://hpux.cs.utah.edu/hppd/cgi-bin/search?package=on&description=on&term=gcc

you need to install the runtime dependencies to use the package above. but on this page you get every info you need to get the packages running.

[vajava_xxx]

to Krackowizer:
yes, I know this site, but I need gcc433, that ther's no yet.

to Schweda:
> Do you have any evidence that this compiler
> works (properly)? I do not expect a working
> compiler to complain about system header
> files ("/usr/include/sys/_inttypes.h",
> "/usr/include/sys/types.h", ...).
>>Still waiting for an answer to that one.
I try hp-gcc-4.3.1, which hp-ux 11.23 bundled. try with the same result. now I may prove it works properly?

the work specificity of this host is have many diferent version compilers. some of them install from package (hpux.cs.utah.edu), some builds from source -like in this case.

[Johannes Krackowizer]

Did you install all depencies for compiling gcc? I had some years ago a similar problem compiling gcc 2.xx on hpux 10.20. I got strange error from make but they dont point to the problem, in fact the point at errors in header files from the os and things like that. Then i found a nice manual somewhere in the internet that told me to install about 30-40 packages from http://hpux.cs.utah.edu and than i was able to compile.

Perhaps you should look at the Build time dependencies on http://hpux.cs.utah.edu (even if it is for gcc 4.2.3) and install the packages you are missing and then try to compile gcc 433.

[Steven Schweda]

> I try hp-gcc-4.3.1, which hp-ux 11.23
> bundled. try with the same result.

What, exactly, did you get where? Tried
what, exactly?

> now I may prove it works properly?

If "now" was intended to be "How", then show
that you can compile a simple test program.
Ideally, a test program which includes the
header file which gets the complaints. For
example:

dyi # cat hm.c
#include
#include

int main()
{
printf( "Hi, Mom!\n");
}

dyi # gcc -o hm hm.c

dyi # ./hm
Hi, Mom!

dyi # gcc -v
Using built-in specs.
Target: ia64-hp-hpux11.31
Configured with: ../gcc-4.3.2/configure
Thread model: posix
gcc version 4.3.2 (GCC)

dyi # type gcc
gcc is hashed (/usr/local/bin/gcc)


> [...] and set some variable like SHLIB_PATH
> and LD_LIBRARY_PATH.

Have you tried it without this stuff? After
that, I'd start by throwing away all those
other "configure" options, and bringing back
only what is needed to get the job done.

[vajava_xxx]

bash-3.00$ gcc -v
Using built-in specs.
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4.3.1 --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-languages=c,c++ --with-gmp=/proj/opensrc/be/ia64-hp-hpux11.23 --with-mpfr=/proj/opensrc/be/ia64-hp-hpux11.23
Thread model: posix
gcc version 4.3.1 (GCC)
bash-3.00$
bash-3.00$ type gcc
gcc is hashed (/opt/hp-gcc/bin/gcc)
bash-3.00$ gcc -o hm hm.c

bash-3.00$ ./hm
Hi, Mom!

[Steven Schweda]

> bash-3.00$ gcc -v
> [...]

Ok. You seem to have a working GCC 4.3.1.
How did you get it? Then what happened?

As I said, I had no trouble building 4.3.2
on my 11.31 system. I've started building
4.3.3 in my usual way:

dyi # mkdir gcc-4.3.3_obj
dyi # cd gcc-4.3.3_obj
dyi # ../gcc-4.3.3/configure 2>&1 | tee ../gcc-4.3.3_configure.out
dyi # gmake bootstrap-lean 2>&1 | tee ../gcc-4.3.3_gmake.out

It's still cooking, but there's no sign of
trouble after a couple of hours.

If you're using a working compiler, and
you're still seeing those complaints about
system header files and that stuff in
regex.c, then I'd suggest looking into all
the config.log and config.status files you
can find.

Around here, for example:

dyi # pwd
/usr/local/gnu/gcc/gcc-4.3.3_obj
dyi # find . -name '*.h' -exec grep STDC_HEADERS {} \; -exec ls {} \;
#define STDC_HEADERS 1
./intl/config.h
#define STDC_HEADERS 1
./libiberty/config.h
#define STDC_HEADERS 1
./gcc/auto-host.h
#define STDC_HEADERS 1
./build-ia64-hp-hpux11.31/libiberty/config.h
#define STDC_HEADERS 1
./build-ia64-hp-hpux11.31/fixincludes/config.h
#define STDC_HEADERS 1
./fixincludes/config.h
#define STDC_HEADERS 1
./libcpp/config.h
#define STDC_HEADERS 1
./libdecnumber/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/hpux64/libgomp/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/hpux64/libstdc++-v3/include/ia64-hp-hpux11.31/bits/c++config
.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/hpux64/libstdc++-v3/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/hpux64/libiberty/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/hpux64/libssp/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/libgomp/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31/bits/c++config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/libstdc++-v3/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/libiberty/config.h
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/libssp/config.h
#define STDC_HEADERS 1
#define STDC_HEADERS 1
./ia64-hp-hpux11.31/libgfortran/confdefs.h
dyi #


So, seeing STDC_HEADERS defined in
libiberty/config.h, I would not expect to
get those complaints about
libiberty/regex.c:130 (and its friends).
(And _I_ don't get them.)

[Steven Schweda]

Yup. Still works:

dyi # gcc -v
Using built-in specs.
Target: ia64-hp-hpux11.31
Configured with: ../gcc-4.3.3/configure
Thread model: posix
gcc version 4.3.3 (GCC)