Apache OpenOffice (AOO) Bugzilla – Issue 1041
gcc build on IRIX
Last modified: 2003-12-06 14:52:34 UTC
I have been able to get the bootstrap complete using gcc and libstdc++ with the small addition of <limits> from SGI's stl.
Created attachment 280 [details] IrixMipsEnv.Set
Created attachment 281 [details] unx.mk : added IRIX/gcc build
Created attachment 282 [details] unxirxm9.mk : build conf for IRIX/gcc
Sander .. I have called the IRIX/gcc mk file 'unxirxm9.mk' due to a lack of a better name. Please feel free to rename it to fit the naming convention. The IrixMipsEnv.Set has several manual changes to it ... obviously COM CVER and also I have removed several -I/usr/include from the include path, as gcc needs to include its own stdarg.h rather than /usr/include/stdarg.h Using this approach, only bug 795 and bug 1040 were visible.
Hi John, hi Sander, I would suppose to name the Irix/gcc combo "unxirgm". This would be similiar to "unxsogs" for Solaris/gcc. Numbers are used for vastly different versions of the same platform/compiler combo.
Created attachment 291 [details] solenv/inc/unx.mk : Patch to allow IRIX/gcc build - take 2
Created attachment 292 [details] Script to fix IrixMipsEnv.Set
Due to the complexity of the build configuration (autoconf, perl, tcsh and dmake), and the possibility of this approach not working ... I have decided to leave the IRIX/gcc build as a hack, modifying only the tcsh and dmake components. Here is the steps I use ... % cd $SRC_ROOT % patch -p0 < attachment291 [details] % mv attachment282 [details] solenv/inc/unxirgm.mk % cd config_office % ./configure --enable-sgistl --with-jdk-home=/path/to/jdk1.2.2 % cd .. % ./attachment292 [details] % source IrixMipsEnv.Set % mkdir -p solver/$UPD/unxirxm3.pro/inc % cp /usr/include/CC/limits solver/$UPD/$INPATH/inc % patch -p0 < bug795attachment290.diff % patch -p0 < bug1074.diff % ./bootstrap (this will break in external/neon due to bug 1073) % cp external/expat/rtufiles/xmlparse/xmlparse.h external/neon/rtufiles/ % ./bootstrap % dmake (this broke last time I built in idlc) If it is possible, can attachment 282 [details] be pushed in as solenv/inc/unxirgm.mk , attachment 291 [details] should be able to go straight in, and it would be useful if the attachment 292 [details] is pushed in as config_office/irix_gcc_fix.tcsh . Once this is done we can create a 'build instructions page' for IRIX.
.map files are also a problem
Some additional problems I have had ... % patch -p0 < bug1077 (this patch has only been tested from unotools onwards at present. If you patch this before the build ... please tell me if you are successful) external/freetype doesnt compile as is ... % cp -r freetype-2.0.2/include/* $wa/external/unxirxm3.pro/inc/ I also found problems with sandbox in OO632B, which is fixed in latest ... I dont remember all the revision numbers I used ... but essentially I had to use the revision that had a log message 'removed makefile.pmk' % cvs co -r MAIN sandbox/*/makefile.mk
I also had to force vos:: in vcl/unx/source/app/salinst.cxx by adding #undef _VOS_NO_NAMESPACE to line 327 of v1.9
Second problem with libstdc++ ... vector does not have ::at , and it seems framework/source/classes/framecontainer.cxx uses this.
Created attachment 301 [details] Patch to add vector< >::at
gcc 3.0 does have vector<..>::at While this is not a very safe ::at .. it seems to do it the trick... % cp /usr/freeware/lib/gcc-lib/mips-sgi-irix6.2/2.95.2/include/g++/stl_vector.h solver/632/unxirxm3.pro/inc/ % patch -p0 < attachment301 [details]
Created attachment 304 [details] Have no idea what impact this has ... keeps the build going tho
And it all falls over at so_berkleydb, so I removed so_berkleydb from makefile.rc , built it myself following the instructions ... and did a make install, which by default installs to /usr/local/BerkeleyDB.3.2/ % cd so_berkleydb % gtar -xzf download/db-3.2.9.tar.gz % cd db-3.2.9/build_unix % ../dist/configure --enable-dynamic --enable-java=/path/to/java --enable-cxx % cp -r /usr/local/BerkeleyDB.3.2/include solver/632/unxirxm3.pro/inc/berkeleydb/ % cp /usr/local/BerkeleyDB.3.2/lib/libdb* $wa/solver/632/unxirxm3.pro/lib/ I then had to hand link sfx2 because of checkdll complaining about a missing symbol _$_Db2 ... this is probably a bug ... but I want to complete the build to confirm its not checkdll being more careful than possible when using gcc and mipspro ld.
bridges built even though it passes over what looked like arch specific directories ... and no mips-irix combination.
Hi john, you should really be submitting patches against set_soenv.1 for now instead of changing the .set file. I'll add some of the others in and then record which ones.
Oh, and the code in the arch specific directories needs to be written. Yes, it does pass over it. OTOH, you should probably first try to get all the other parts compiling ready first as I think it is possible to get a working office without it (if my memory from the early ppc port days isn't wrong).
Okey, I am closing this as resolved: * unx.mk patch commitied in both OO632B and HEAD * unxirgm.mk added and tagged as OO632B * patch for setup2/source/custom/jvmsetup/unx/jvmscan.cxx applied in both HEAD and OO632B
I am sorry but configure.in and set_soenv.1 are a mess, with only 13 or so parameters as communication between the two, and its not worth my time getting those two to talk together in a useful way, to enable the IRIX port to possibly use CC with SGI STL or STLport , or use gcc with STLport or libstdc++. Before I can make any changes to set_soenv.1, I have yet to get the two to even allow a gcc build on IRIX. I spent a day trying and failed. Anyway I can understand not putting the script in ... I can include the contents of it on the IRIX build page anyway ... dont knw why I didnt think of that before asking.
Three days of nursing a build along ... and I have a soffice.bin % ldd ./soffice.bin libsvx632im.so => ../lib/libsvx632im.so libcomphelp2.so => ../lib/libcomphelp2.so libsal.so.2.0.0 => ../lib/libsal.so.2.0.0 libvos2GCC.so => ../lib/libvos2GCC.so libtl632im.so => ../lib/libtl632im.so libcppu.so.2.0.0 => ../lib/libcppu.so.2.0.0 libcppuhelper2GCC.so => ../lib/libcppuhelper2GCC.so libsfx632im.so => ../lib/libsfx632im.so libsb632im.so => ../lib/libsb632im.so libso632im.so => ../lib/libso632im.so libj632im_g.so => ../lib/libj632im_g.so libtk632im.so => ../lib/libtk632im.so libsvt632im.so => ../lib/libsvt632im.so libset632im.so => ../lib/libset632im.so libsvl632im.so => ../lib/libsvl632im.so libofa632im.so => ../lib/libofa632im.so libvcl632im.so => ../lib/libvcl632im.so libsot632im.so => ../lib/libsot632im.so libutl632im.so => ../lib/libutl632im.so libpthread.so => /usr/lib32/libpthread.so libX11.so.1 => /usr/lib32/libX11.so.1 libm.so => /usr/lib32/libm.so libc.so.1 => /usr/lib32/libc.so.1 libxo632im.so => ../lib/libxo632im.so libgo632im.so => ../lib/libgo632im.so libucbhelper1GCC.so => ../lib/libucbhelper1GCC.so libdbtools2.so => ../lib/libdbtools2.so libfwe632im.so => ../lib/libfwe632im.so libsts632im.so => ../lib/libsts632im.so libdb-3.2.so. => ../lib/libdb-3.2.so. libdb_cxx-3.2.so. => ../lib/libdb_cxx-3.2.so. libxcr632im.so => ../lib/libxcr632im.so libXt.so => /usr/lib32/libXt.so libXmu.so => /usr/lib32/libXmu.so libsalhelper2GCC.so => ../lib/libsalhelper2GCC.so libXext.so => /usr/lib32/libXext.so libbasctl632im.so => ../lib/libbasctl632im.so libpsp632im.so => ../lib/libpsp632im.so libXaw.so.2 => /usr/lib32/libXaw.so.2 libgen.so => /usr/lib32/libgen.so delay-load Running soffice.bin results in ~100 unresolved symbols ... in svx, ofa and basctl Running setup.bin results in Abort in crypt.c, which doesnt appear in the tree, so more fun to be had there.
Created attachment 315 [details] solenv/inc/tg_ext.mk : Patch to get so_berkleydb to dmake/deliver
To remove rld errors from soffice, I had to use ld to link all dso's, which still broke on berkleydb, which uses gcc to link even if it has been told to use ld, so a manual link of libdb_cxx using ld is required. This results in a soffice.bin that also calls Abort in crypt.c.
I am seeing in 633, the problem fixed on 632 by attach 304: setup2/source/custom/jvmsetup/unx/jvmscan.cxx
adding myself to cc list
changing QA contact from bugs@ to issues@
Is this still around (which of the issues in here) or can it be closed?
We have not been working on the gcc-3/libstdc++ port, but concentrating on gcc-2.95/STLport-4.5 (this seems to be the path of least resistance!). However, the only thing here that still looks relevant is the vector< >::at stuff, and it is probably worth keeping this until such time as we get back to looking at gcc-3.0 (which will happen sometime, given that gc-2.95 is so buggy and does not produce debug binaries in most cases).
issuezilla cleanup closing as 'LATER' due to no activity - please reopen when the gcc3/libsdtc++ port is again active
Verifying issue, please close.
Will reopen once the gcc3/libstd++ port is underway.