You should not configure and make open64 in the top directory of the source file. Please do the following steps
$ cd open64-src $ mkdir objs $ cd objs $ ../configure --prefix=<you prefer dir> $ make && make install On Mon, Dec 5, 2011 at 8:01 AM, Matthias Grobarek <unclep...@gmx.de> wrote: > Hi. I am unable to build Open64 5.0 from the source package under Linux > x86-64. After a while compiling, I encounter the following error: > > > gcc -m32 -DKEY -DOPEN64_SPIN -DFE_GNU_4_2_0 -O2 -DTARG_X8664 -DIN_GCC -W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o > cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o > c-decl.o > c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o > c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o > c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o > c-pretty-print.o c-omp.o dummy-checksum.o \ > main.o libbackend.a ../../osprey/targdir/libspin_4_2_0/libgspin42.a > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a > gcc: ../../osprey/targdir/libspin_4_2_0/libgspin42.a: No such file or > directory > make[4]: *** [cc1-dummy] Error 1 > make[4]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0/osprey-gcc-4.2.0/host-x86_64-redhat-linux/gcc' > make[3]: *** [all-gcc] Error 2 > make[3]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0/osprey-gcc-4.2.0' > make[2]: *** [all] Error 2 > make[2]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0/osprey-gcc-4.2.0' > make[1]: *** [osprey-gcc-4.2.0/gcc/cc1] Error 2 > make[1]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0' > make: *** [build] Error 2 > > > I figured out that this error probably comes from then makefile > $SRC/osprey-gcc-4.2.0/gcc/Makefile.in which tries to point to libgspin42.a but > uses the wrong directory (one ../ is missing, see attached patch). But when I > fixed this, gcc wasn’t happy either: > > > gcc -m32 -DKEY -DOPEN64_SPIN -DFE_GNU_4_2_0 -O2 -DTARG_X8664 -DIN_GCC -W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o > cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o > c-decl.o > c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o > c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o > c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o > c-pretty-print.o c-omp.o dummy-checksum.o \ > main.o libbackend.a ../../../osprey/targdir/libspin_4_2_0/libgspin42.a > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a > libbackend.a(toplev.o): In function `toplev_main': > toplev.c:(.text+0x200b): warning: the use of `tempnam' is dangerous, better > use > `mkstemp' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: > i386:x86-64 architecture of input file > `../../../osprey/targdir/libspin_4_2_0/libgspin42.a(gspin-tree.o)' is > incompatible with i386 output > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: > i386:x86-64 architecture of input file > `../../../osprey/targdir/libspin_4_2_0/libgspin42.a(gspin-mempool.o)' is > incompatible with i386 output > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: > i386:x86-64 architecture of input file > `../../../osprey/targdir/libspin_4_2_0/libgspin42.a(gspin-io.o)' is > incompatible with i386 output > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: > i386:x86-64 architecture of input file > `../../../osprey/targdir/libspin_4_2_0/libgspin42.a(gspin-tel.o)' is > incompatible with i386 output > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: > i386:x86-64 architecture of input file > `../../../osprey/targdir/libspin_4_2_0/libgspin42.a(gspin-list.o)' is > incompatible with i386 output > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: > final link failed: Invalid operation > collect2: ld returned 1 exit status > make[4]: *** [cc1-dummy] Error 1 > make[4]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0/osprey-gcc-4.2.0/host-x86_64-redhat-linux/gcc' > make[3]: *** [all-gcc] Error 2 > make[3]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0/osprey-gcc-4.2.0' > make[2]: *** [all] Error 2 > make[2]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0/osprey-gcc-4.2.0' > make[1]: *** [osprey-gcc-4.2.0/gcc/cc1] Error 2 > make[1]: Leaving directory > `/var/tmp/portage/dev-lang/open64-5.0/work/open64-5.0' > make: *** [build] Error 2 > > > Taking a look at the libgspin42.a file shows that it contains 64-bit object > files. So I assume that gcc needs 32-bit object files at this point > and thus fails. Which seems a bit odd to be since this was my ./configure > line: > > > ./configure --prefix=/usr/local --disable-fortran > --build=x86_64-unknown-linux-gnu > > > I thought – according to the build instructions from > http://www.open64.net/?id=254 – that setting the --build option to x86_64 > ensures that > everything (executeables as well as libs) will be compiled as 64-bit? > > --- > > Some details regarding my system: > > OS: Gentoo Linux, x86-64 > > # uname -a > Linux pain2 3.1.0-gentoo #1 SMP PREEMPT Mon Nov 7 15:21:39 CET 2011 x86_64 > AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux > > # gcc --version > gcc (Gentoo 4.4.5 p1.3, pie-0.4.5) 4.4.5 > > # make --version > GNU Make 3.82 > Built for x86_64-pc-linux-gnu > > --- > > Regards, > > > Matthias > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > -- yongchong ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
