alliance-support '02
Re: problem building ocp under Cygwin 1.3.9 under Windows98SE and Linux 2.4.8 with gcc 2.95.3-5 and 3.0.3


Christophe Alexandre (Christophe.Alexandre@asim.lip6.fr)
Tue, 29 Jan 2002 10:33:16 +0100 (CET)

Hi Art, I've worked on ocp and I think that the changes I've commited will fix the problems you had with its compilation with gcc 3. There was a problem with the namespaces. gcc 3 is more restrictive with the utilisation of standards libraries. Still, I've got a few problems I'll try to fix. Example: I must include hash_map.h and not hash_map. I'm not sure that it's not a problem with the local gcc 3 installation. For the installation under Cygwin, have you got the last distribution of libtool? Your version does not seem to recognize your system? Once you've got it run the autogen.sh script before running configure and make. The Makefile in the ocp directory will do that. Christophe Alexandre On Sun, 27 Jan 2002, Art wrote: > Hi! > > Please advise on Linux build environment. > > I had successfully built Alliance 4.5.0 early this month under Cygwin 1.3.5 > so I wanted to test my build process under Linux 2.4.8 (Mandrake 8.1) and > it failed on ocp! So, I tried to rebuild under Cygwin 1.3.9 with gcc > 2.95.3-5 > to isolate the cause, it failed too - in a different fashion! > I want to fix my Linux build first, but I'll describe the Cygwin errors > first. > This is the output from "make": > In ~/ws/all_obj/ocp: > > checking host system type... i686-pc-cygwin > checking for style of include used by make... GNU > checking for gcc... gcc > checking for C compiler default output... a.exe > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for executable suffix... .exe > checking for object suffix... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking dependency style of gcc... gcc > checking for ld used by GCC... /usr/i686-pc-cygwin/bin/ld.exe > checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes > checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object > files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependant libraries... file_magic file format > pei*-i38 > 6(.*architecture: i386)? > checking command to parse /usr/bin/nm -B output... ok > checking how to run the C preprocessor... gcc -E > checking for dlfcn.h... yes > checking for ranlib... ranlib > checking for strip... strip > checking for gcc option to produce PIC... none > checking whether the linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared > lib > raries... yes > checking command to parse /usr/bin/nm -B output... (cached) ok > checking if gcc static flag -static works... yes > checking the maximum length of command line arguments... 786433 > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking if gcc supports -c -o file.o... yes > checking for objdir... .libs > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... Win32 ld.exe > checking whether -lc should be explicitly linked in... yes > creating libtool > checking if libtool supports shared libraries... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... gcc > checking how to run the C++ preprocessor... g++ -E > ltconfig: unrecognized option `--build=i686-pc-cygwin' > Try `ltconfig --help' for more information. > configure: error: libtool tag configuration failed > make: *** [all] Error 1 > > --- end Cygwin output --- > Well, this points to a lack of synchronization between "ltconfig" and its > parent... so I'll pursue that later. > > On Linux, I get: > > bash-2.05# make > make[1]: Entering directory `/home/ws/all_obj/ocp/Linux_tmp' > Making install in src > make[2]: Entering directory `/home/ws/all_obj/ocp/Linux_tmp/src' > Making install in common > make[3]: Entering directory `/home/ws/all_obj/ocp/Linux_tmp/src/common' > source='../../../src/common/PCommon.cpp' object='PCommon.o' libtool=no \ > depfile='.deps/PCommon.Po' tmpdepfile='.deps/PCommon.TPo' \ > depmode=gcc3 /bin/sh ../../../depcomp \ > g++ -DPACKAGE=\"ocp\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DYYTEXT_POINTER=1 > -g > -O2 -Wall -DALLIANCE_VERSION='"4.5.0"' -DMUT_H="<mut325.h>" -DMPH_H="<mph413 > .h>" > -DMPU_H="<mpu408.h>" -DMLO_H="<mlo502.h>" -DMLU_H="<mlu502.h>" -DABL_H="<ab > l103 > .h>" -I. -I../../../src/common -I../../../src/common -I/home/ws/all_obj/arch > i/Li > nux/include -g -O2 -Wall -c -o PCommon.o `test -f > ../../../src/common/PCommon > .cpp || echo '../../../src/common/'`../../../src/common/PCommon.cpp > ../../../src/common/PCommon.cpp: In function `bool IsTie(const phins*)': > ../../../src/common/PCommon.cpp:53: `string' undeclared (first use this > function) > ../../../src/common/PCommon.cpp:53: (Each undeclared identifier is reported > only once for each function it appears in.) > ../../../src/common/PCommon.cpp:53: parse error before `(' token > ../../../src/common/PCommon.cpp:55: `figname' undeclared (first use this > function) > ../../../src/common/PCommon.cpp:55: parse error before `::' token > ../../../src/common/PCommon.cpp:57: parse error before `::' token > ../../../src/common/PCommon.cpp:60: confused by earlier errors, bailing out > make[3]: *** [PCommon.o] Error 1 > make[3]: Leaving directory `/home/ws/all_obj/ocp/Linux_tmp/src/common' > make[2]: *** [install-recursive] Error 1 > make[2]: Leaving directory `/home/ws/all_obj/ocp/Linux_tmp/src' > make[1]: *** [install-recursive] Error 1 > make[1]: Leaving directory `/home/ws/all_obj/ocp/Linux_tmp' > make: *** [all] Error 2 > --- end Linux output --- > > Ok. Here I did some tweaking! > For some reason gcc 3.0.3 did not like "#include <iostream>", so I added > this > code to the top of PBBox.cpp and PCommon.cpp which eliminated the errors > I was getting with "ostream&" being "bad syntax": > > #ifdef __linux__ > # include <iostream.h> > #endif > > This improved the results but was not enough to compile. > I tried "#include <cstring>" to fix the error on line 53 of PCommon.cpp with > 'string' undeclared, but this didn't fix it. > > It's been a while since I played with C++ and I know ISO C++ has brought > many > changes with gcc 3.0.3, so I'd like more advice on the build environment. > ltconfig (GNU libtool) 1.3.4 (1.385.2.196 1999/12/07 21:47:57) > automake (GNU automake) 1.5 > autoconf (GNU Autoconf) 2.52 > aclocal (GNU automake) 1.5 > > Cygwin has the same tools, except for: > gcc 2.95.3-5 > automake (GNU automake) 1.5b > aclocal (GNU automake) 1.5b > > BTW, I lost the exec flag on all my files when I transferred them from > Cygwin > to Linux - I used Zip which apparently is naive of the '+x' execute flag, so > I made changes to many scripts to execute: > > sh ./script_name > vs > ./script_name > > I could've used "tar" to preserve the "rwx" flags, but didn't worry at the > time I archived, since I was thinking "update" works great with zip and I > don't trust it in GNU tar (Unix tar does not support it). > > BTW, I am still building in a tree independent of the source tree - I just > archived my change files, which are mostly Makefile's and I just compare > them to the ones in the new releases which don't change much. > > Thanks & Regards, > > Art > > --

 



Alliance Web Site © 1997, 2002 ASIM/LIP6/UPMC, page maintained by Czo [Olivier Sirol] , last updated on 02 February 2002.