Why not fix the problem to let it build in the top of trunk. On Sat, Dec 10, 2011 at 9:43 AM, Yiran Wang <yiran.w...@gmail.com> wrote: > I think we may add some detection of this pitfall, as it is a bit common, > i.e. to have a brief look if it is the top-level directory of open64 source > in "configure". > > Best Regards, > Yiran > > On Thu, Dec 8, 2011 at 9:27 PM, Wu Yongchong <wuyongch...@gmail.com> wrote: >> >> 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 > >
-- yongchong ------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
