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.