Apache OpenOffice (AOO) Bugzilla – Issue 1209
IRIX / gcc 2.95.2 / STLport
Last modified: 2010-03-29 19:56:28 UTC
This is a meta bug for issues related to the port: IRIX / gcc 2.95.2 / STLport Here are some general notes: --- STLport-0609 --- I have been able to build STLport on IRIX using gcc 2.95.2. The changes have not yet made it into a STLport release ... however the changes are available at: http://www.stlport.com/dcforum/DCForumID5/489.html In udkapi, idlc reported errors preprocessing the first .idl file idlc was invoking idlcpp (also in module idlc), which was core dumping. The core reported problems in std::__Locale. For not apparent reason it was linked against -lstlport_gcc. I hand linked it and all was well. It seems SGI ld links dso's in even if no symbols are needed from that dso. The core could be a result of stlport_gcc expecting symbols in the binary. I say this as many of the tools being used to build link against stlport_gcc, but do not result in such errors. Solution ... hand link idlcpp without -lstlport_gcc --- build / dmake / ld --- fw_dmake does not work, as OpenOffice has its own dmake. The open office build emits very long command lines, which exceed the default IRIX ncargs setting. To solve this run the following command as root. -r makes the changes only affect the running system. % systune -r ncargs 0x10000 SGI ld breaks on the size of several dso's (svx is one example). To solve this problem, change to the directory where the build breaks, and run % dmake -n > dmake.tcsh % vi dmake.tcsh find the line that begins ... 'echo gcc ... -shared' and add -Wl,-LD_LAYOUT:lgot_buffer=20 From memory one dso required =30. Another problem I have found is that the order of libraries in the makefiles causes problems with SGI ld. I will raise bugs when I find them, however the solution is always to place .a files before .so files on the ld command line (and hence the gcc command line which invokes ld) --- fw_gcc 2.95.2 --- gcc 2.95.2 has several problems on IRIX It often core dumps when building with -g. This becomes evident when building with 'dmake debug=true'. Simply change into the directory where the build broke, remove the core, and build that file with 'dmake'. Also SGI nm does not like some object files and dso's output by gcc. binutils is no better. % /usr/bin/nm libofa632mi.so libofa632mi.so ERROR: dwarf_elf_init: DW_DLE_DEBUG_LINE_NULL (38) .debug_line section present but elf_getdata() failed or section is zero-length % /usr/local/binutils-2.11.2/bin/nm libofa632mi.so /usr/local/binutils/bin/nm: libofa632mi.so: no symbols The openoffice build makes use of nm, and the solution to this is to strip the object or dso. --- fw_gdb 5.0 --- dbx core dumps on me when loading almost any binary in the OpenOffice build. % dbx soffice.bin core dbx version 7.3.1 68542_Oct26 MR Oct 26 2000 17:50:34 Client I/O fault: Read failed: Broken pipe The debugger server has apparently terminated for some reason. You will have to restart your debugging session. gdb 5.0 will load the binary, however if it is linked against pthreads, gdb is rendered useless. (gdb) info threads (gdb) backtrace #0 0xfafb344 in prctl () at sesmgr_t6net.c:478 #1 0xc24e01c in pthread_kill () at sig.c:149 #2 0xc24f000 in _SGIPT_libc_raise () at sig.c:660 #3 0xc247bf4 in ptctl () at libcthread.c:177 #4 0xfadefe8 in raise () at iconv_converter.c:14277 (gdb) However, currently the pthreads library is linked into every binary in the IRIX build, even if it doesnt use pthreads (SGI ld links the dso in even if no symbols are needed from the dso). This is really another bug. So the solution is to try to manually link the binary without the -lpthread. If the the binary actually need pthreads, it seems a seg fault will ensure that pthreads does not clean up, destroying the core file. So rather than using 'printf' to debug, simply generate a seg fault where you wish to inspect the code. pthread_kill(thread_self(),SIGSEGV); --- berkeleydb 3.2.9 --- Berkely db (so_berkeleydb) does not build properly in 632, and will need to be built separately. The source is in the openoffice tree so_berkleydb/download. Unzip and configure with --enable-cxx --enable-java --enable-dynamic --enable-shared The problem is libdb_cxx.so ends up with undefined symbols ostream and cerr. The solution is to change the Makefile to build .cxx files with -nostdinc++ -I/usr/local/STLport-0601/stlport and build the dso with -L/usr/local/STLport-0601/lib -lstlport_gcc (substitute the path to STLport as appropriate) You will then need to copy db.h and db_cxx.h into solver/.../inc , .libs/libdb* into solver/.../lib , and classes/db.jar into solver/.../bin . --- OpenOffice --- As yet there are numerous other problems I have found building on IRIX ... see Issue 1041 for details. Current status: svdem in vcl works svdem in svtools starts, however it core dumps if you click around much setup in instsetoo starts, starts the underlying setup .... goes thru several pages then core dumps.
Outstanding issues from previous ports which are applicable to this port.
After building STLport-0601, installing fw_gcc 2.95.2 and jdk-1.2.2, these are the steps. Apply patch in Bug 1211, and copy the attachment in Bug 1216 over solenv/inc/unxixgm.mk , and run configure % patch -p0 < bug1211 % cp bug1216 solenv/inc/unxixgm.mk % cd config_office % autoconf % setenv CC gcc % setenv CXX g++ % ./configure --with-stlport4-home=/path/to/STLport-0601/ --with-jdk- home=/path/to/java_1.2.2/usr/java/ % cd .. % setenv CC gcc % setenv CXX g++ % setenv COM GCC % setenv CVER C295 % ./bootstrap (This will break several times ... see bugs for details)
Woops ... not quite ... after running configure ... % vi IrixMipsEnv.Set and remove all -I/usr/include 's from SOLARINC % source IrixMipsEnv.Set % setenv COM GCC % setenv CVER C295 % vi bootstrap and comment out the "source IrixMipsEnv.Set" % ./bootstrap
These two problems may be specific to the current developer release of STLport.
Created attachment 537 [details] tools/bootstrap/command.cxx -- against OO638C, previous was against OO638B
Argh, ignore that last attachment, sorry, fighting with IssueZilla...
changing QA contact from bugs@ to issues@
tracked internal as 95564
Added myself to cc list, and updated with issues we need to fix before OOO_STABLE_1 is ready (build-wise, anyway) for IRIX.
adding myself too
Not sure why this was P1 or set for 1.0.3
per issue 106845 sb removed the partial irix port, so this doesn't make sense in isolation anymore106845
closing