Issue 1209 - IRIX / gcc 2.95.2 / STLport
Summary: IRIX / gcc 2.95.2 / STLport
Alias: None
Product: porting
Classification: Code
Component: documentation (show other issues)
Version: 632
Hardware: SGI IRIX
: P4 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: sander_traveling
QA Contact: issues@porting
Depends on: 795 804 1040 1073 1074 1080 1081 1097 1107 1109 1211 1215 1216 1219 1220 1221 1223 1881 8110 8112 8113 8146 8202 8258 8263
  Show dependency treegraph
Reported: 2001-07-13 03:20 UTC by issues@www
Modified: 2010-03-29 19:56 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---

tools/bootstrap/command.cxx -- against OO638C, previous was against OO638B (645 bytes, patch)
2001-10-02 22:17 UTC, nickb
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description issues@www 2001-07-13 03:20:36 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:

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 


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 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
/usr/local/binutils/bin/nm: 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

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.  


--- 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 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.
Comment 1 issues@www 2001-07-13 04:28:03 UTC
Outstanding issues from previous ports which are applicable to this port.
Comment 2 issues@www 2001-07-13 07:22:30 UTC
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/ , and run configure

% patch -p0 < bug1211
% cp bug1216 solenv/inc/
% cd config_office
% autoconf
% setenv CC gcc
% setenv CXX g++
% ./configure --with-stlport4-home=/path/to/STLport-0601/ --with-jdk-
% cd ..
% setenv CC gcc
% setenv CXX g++
% setenv COM GCC
% setenv CVER C295

% ./bootstrap

(This will break several times ... see bugs for details)
Comment 3 issues@www 2001-07-13 07:36:48 UTC
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
Comment 4 issues@www 2001-07-13 16:28:11 UTC
These two problems may be specific to the current developer release of STLport.
Comment 5 nickb 2001-10-02 22:17:38 UTC
Created attachment 537 [details]
tools/bootstrap/command.cxx -- against OO638C, previous was against OO638B
Comment 6 nickb 2001-10-02 22:19:58 UTC
Argh, ignore that last attachment, sorry, fighting with IssueZilla...
Comment 7 Unknown 2001-11-08 22:53:03 UTC
changing QA contact from bugs@ to issues@
Comment 8 Martin Hollmichel 2001-12-04 14:51:54 UTC
tracked internal as 95564
Comment 9 nickb 2002-10-30 12:51:09 UTC
Added myself to cc list, and updated with issues we need to fix before
OOO_STABLE_1 is ready (build-wise, anyway) for IRIX.
Comment 10 Unknown 2002-10-30 21:43:00 UTC
adding myself too
Comment 11 nickb 2003-04-04 08:52:21 UTC
Not sure why this was P1 or set for 1.0.3
Comment 12 caolanm 2010-03-29 19:55:55 UTC
per issue 106845 sb removed the partial irix port, so this doesn't make sense in
isolation anymore106845
Comment 13 caolanm 2010-03-29 19:56:28 UTC