I passed the "make all" stage but could not compile the libraries.
/bin/sh: Syntax error: redirection unexpected make: *** [lib] Error 2
Never mind. "SHELL=/bin/bash" solves the problem. But I only build the x86_64 targets. I386 failed to build because no compatible libgcc was found.
But it did not compile.
$ openCC-22.214.171.124 -O2 fac.cc -L$HOME/open64/lib/gcc-lib/x86_64-open64-linux/126.96.36.199 /usr/bin/ld: skipping incompatible /home/me/open64/lib/gcc-lib/x86_64-open64-linux/188.8.131.52/libopen64rt.a when searching for -lopen64rt /usr/bin/ld: skipping incompatible /home/me/open64/lib/gcc-lib/x86_64-open64-linux/184.108.40.206/libopen64rt.a when searching for -lopen64rt /usr/bin/ld: cannot find -lopen64rt collect2: ld returned 1 exit status
Sounds like you didn't build the libraries, per the README file:
make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP make -C osprey/targx8664_builtonia32 BUILD_COMPILER=OSP
I did build the library but I built it with MACHINE_TYPE=x86_64. In fact, you can see in my attached code that openCC discovered the library under the directory but found it incompatible.
For some reason I cannot build the i386 compiler and library.
Note that the recently released 4.2.3 compiler includes new information in the INSTALL file describing changes made than enabled us to build from source on both Ubuntu 8.10 and 9.10 and then use the next generation compiler to build itself and the libraries.
Some quick highlights of the exercise:
(0) Make sure you get pre-requisite packages installed. *multilib versions of libraries are particularly important - otherwise you'll see some of the incompatible libraries messages.
(1) Our 1st generation Open64 compiler came from the 220.127.116.11 release. We did an untar into the /opt directory and built from there.
(2) Our 2nd generation compiler, we built using the 1st gen compiler setting TOOLROOT and PATH as described in the INSTALL guide. We also applied changes described in the INSTALL file. We found some cases where the 1st gen had some issues with libraries and hence did the ubuntu build with "make lib MACHINE_TYPE=i386 BUILD_COMPILER=GNU". This built the 2nd gen 4.2.3 compiler and libraries without errors.
(3) Our 3rd generation compiler, we built using the 2nd gen compiler, setting TOOLROOT and PATH to point to the 2nd generation. In this case, we were able to do the ubuntu builds with "make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP" as described in the INSTALL information.
I just tried 4.2.3, and it did not work on Ubuntu 9.04.
I admit that I do not have full lib32 installed. But it should not be a problem if I build with MACHINE_TYPE=x86_64. (I do not need to build 32 bit binary on my machine.) When I tried to build the library with "make lib MACHINE_TYPE=x86_64 BUILD_COMPILER=OSP", it stopped at the following error:
MAKE default in /home/duanmu/tmp/x86_open64-4.2.3/libdwarf make first make: Nothing to be done for `first'. make make_libdeps C /home/duanmu/tmp/x86_open64-4.2.3/osprey/targx8664_builtonia32/libdwarf/../../libdwarf/dwarfdump/tag_attr.c /usr/bin/ld: cannot find -lopen64rt collect2: ld returned 1 exit status
I suspect the MACHINE_TYPE=x86_64 is likely cause for differences here.
All of our 4.2.3 ubuntu builds (8.04, 8.10 and 9.10) were done on 64-bit machines. However, compiler itself was built as 32-bit executables+libraries (MACHINE_TYPE=i386) that is then able to generate either 32-bit or 64-bit code. An additional complication that affects the bootstrap is that debian/ubuntu conventions for "/lib vs /lib32" are different than suse/rhat conventions for "/lib vs. /lib64" (a reason for 2nd vs. 3rd gen bootstrap though I don't think the latter is getting you here).
Hence, an ubuntu build sequence we've found to work is:
1. Install 18.104.22.168
2. Build 2nd generation (after applying changes described in INSTALL file)
make all MACHINE_TYPE=i386
make lib MACHINE_TYPE=i386 BUILD_COMPILER=GNU
make -C osprey/targx8664_builtonia32 BUILD_COMPILER=GNU
3. Build 3rd generation (we used a fresh copy of src and after applying changes described in INSTALL file)
make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP
make -C osprey/targx8664_builtonia32 BUILD_COMPILER=OSP
The end result is an ubuntu compiler built as 32-bit executable+libraries along with both 32-bit and 64-bit runtime libraries. This compiler was then able to generate either 32-bit or 64-bit codes.
Sorry we don't support the X86_64 build environment (we never use it internally).
You will need to follow the instructions in section "Notes on Building on Ubuntu 9.10" in the INSTALL file.
Hopefully that should get you going.
Unfortunately I am not the root. With the current configuration, i386 simply won't build. I actually managed to build the x86_64 platform by adding some library paths. The compiler seems to be working except for error "undefined reference to `__ompc_can_fork'" when "-apo" is turned on.
P.S. I do have gcc-4.2.4 installed. However, /usr/lib32/gcc/i486-linux-gnu/ is empty.
[ubuntu:~/tmp/x86_open64-4.2.3]$ make all MACHINE_TYPE=i386 make first make: Entering directory `/home/duanmu/tmp/x86_open64-4.2.3' make -C osprey/targia32_x8664/libspin make: Entering directory `/home/duanmu/tmp/x86_open64-4.2.3/osprey/targia32_x8664/libspin' gcc -m32 -mno-sse2 -D_SGI_SOURCE -D_LANGUAGE_C -Wformat -funsigned-char -D__GNU_BUG_WORKAROUND gspin-test-driver.o libgspin.a -o gspin /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.3/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.3/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status
Originally posted by: duanmu Unfortunately I am not the root. With the current configuration, i386 simply won't build.
The symptoms of your "skipping incompatible libgcc.a" build failure are same as when gcc-multilib package is not installed. So that is unfortunate you don't have root or sudo to add packages to your system. In addition to gcc-multilib you might also be missing g++-multilib, libg32fortran2 and gfortran-4.2-multilib (other 32-bit library packages used in the build).
I agree. But it is interesting that x86_64 can build after some tweaks, which means that the configuration files have some bugs. I still do not get why x86_64 is not supported. Why would anyone use open64 compiler to build 32 bit binaries?
Retrieving data ...