1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Here is some information about common problems when building on SGI
IRIX platforms, sorted in approximate order of your chances of getting
hit by the problem:
1 If linking fails due to problems with an error message about
"Argument list too long", you need to increase the kernel setting
of memory allocated to argument parsing in the shells.
SGI IRIX have a default setting on the buffer available for
shell-argument parsing at an extremely low 20kB. (Other common
platforms like Solaris og HPUX11 have a default buffer of => 1MB
for ARGMAX. Linux-kernels, up to version 2.4, has a default ARGMAX
of 128KB.)
Combined with the peculiar technique of IRIX ld to extract all .o
object-files from ar-archives before linking up a main library from
sub-libraries, this makes the final link command when building Coin
become way too large under many IRIX platforms.
(For more information, see the documentation of the "ncargs" kernel
variable in "Appendix A: Kernel tunable parameters" in IRIX 6.5
Admin: System Configuration and Operation, available online at
<URL:http://techpubs.sgi.com>.)
You can fix this problem once and for all by doing this as root
(ask your sysadmin):
# systune -i
> ncargs 81920
> quit
To make the changes survive a reboot, copy the new kernel over the
old one:
# mv /unix.install /unix
An alternative fix for this (for instance if you don't have root
access to the system, or don't want to lose your uptime count, or
don't have the balls to make and install a new kernel) is to re-run
``configure'' with the "--enable-compact" option.
2 If linking fails with the error messages:
ld: ERROR 48: Cannot access registry file .libs/so_locations ...
ld: FATAL 51: Can't assign virtual addresses for ...
..you're typically trying to link over NFS, which the SGI linker is
not too fond of in certain situations -- as it needs to be able to
lock the so_locations file. If this happens to you, try compiling
and linking on a local disk instead. Or just make a symlink from
the .libs/so_locations file the linker is trying to make to an
empty file (use ``touch'') on a local disk.
3 If linking fails with something like
171230:/usr/lib32/cmplrs/nm_elf: rld: Fatal Error: Cannot
Successfully map soname 'be.so' under any of the filenames
[...]
You've stumbled into an SGI MIPSPro version 7.30 compiler bug. It
can be worked around by setting the environment variable TOOLROOT
to the empty string "", like this (for Bourne Shell):
$ TOOLROOT=""
$ export TOOLROOT
4 If ``make install'' fails in the src/elements/ directory with either
[...]
mkdir -p -- /devlibs/FT_PD_irix-n32-R3/include/Inventor/elements
*** Termination code 138 (bu21)
(for SGI make) or
gmake[3]: *** [install-libelementsincHEADERS] Segmentation fault (core dumped)
(for GNU make), chances are you're running SGI IRIX 6.3, with
configure picking up the Korn Shell (/bin/ksh) for the build
process. ksh seems to have an internal limit which causes the
``make'' tools to freak out when an envvar value has too many
characters. Since there are problems with other standard SGI IRIX
shells (see below), we advice you to install and use the GNU Bourne
Again Shell (bash).
Pre-compiled packages of bash are available from
<URL:http://freeware.sgi.com/>, or you can pick up the sourcecode
at <URL:ftp://ftp.gnu.org/gnu/bash>.
With bash in place, run configure with (assuming you installed bash
in /bin):
$ CONFIG_SHELL=/bin/bash <srcpath>/configure <your-options>
5 An Autoconf bug seems to affect attempts to run configure with
either /bin/sh, /bin/csh or /bin/tcsh. The shell interpreter
complains with "missing }". The best solution seems to be to use
the GNU Bourne Again Shell. See above.
6 Problems with object code formats. Will typically manifest itself
when trying to build code on top of Coin, for instance one of the
So* libraries. A typical error message you will get is like this
(example is from an SoQt configure run):
configure:12022: checking whether libCoin is available
configure:12058: g++ -o conftest -g -O2 -I/coin-instdir/include -O2 -D_REENTRANT -O2 -L/coin-instdir/lib -O2 conftest.cc -lCoin -lGL -lXext -lSM -lICE -lX11 -ldl -lpthread -lm >&5
ld32: FATAL 12: Expecting n32 objects:
/coin-instdir/lib/libCoin.so is o32.
This is a rather classical IRIX problem, not really related
specifically to Coin: IRIX has 3 different types of executables /
shared libraries / object code formats. You can compile code in
"old 32 bits" mode ("o32"), "new 32 bits" mode ("n32") or "new 64
bits" mode ("n64"), and these are *not* interchangeable. This means
that if you want to build an "n32" executable, _all_ the libraries
it depends on must also be in this format.
What the linker is complaining about in this case is that one or
more (or probably all) of the _other_ libraries on the link line is
in "n32" format, while libCoin.so was built as an "o32" library.
You will either have to tell the compiler and linker to use
exclusively "o32" libraries, or better: to rebuild the libCoin.so
library in "n32" format.
This is very likely a local configuration issue with the compiler
and / or linker set-up, which you should get your local IRIX-guru
to investigate.
The above is a complete list of the problems we are aware of on SGI
IRIX platforms when trying to configure and build Coin. If you bump
into any other problems, please let us know.
--
mortene@sim.no
|
