[comp.unix.sysv386] ISC linker reports permissions error

dvb@emisle.emisle (David Van Beveren) (04/25/91)

I am trying to compile and link a test application, which is used to test a set
of libraries being developed. The compile line is as follows:

        cc -g -I. -I/usr/users/nova/include -I/usr/include/X11 -I/usr/include/Xm
 -D_NO_PROTO   -L/usr/users/nova/lib -L/usr/lib -L/usr/lib -L/usr/lib -o tst  ts
t.o  -lScall -lScObj -lScDb -ladt -lbstr -lMem -lScall -lXm -lXt -lX11 -linet

Partway into the link, I am receiving the following error:

ld fatal: fail to write symbol name background_pixmap in string table for file t
st
*** Error code 13

Error code 13 means Permission Denied. I assume the symbol table has gotten
too big, like beyond the User-filesize limit. How do I change this limit to
accomodate me? I tried compiling as root, and got the same result. What is
the solution?

System is ISC 2.0.2, dev system is ISC 2.0. 

P.S. The file system being used has ~5MB free.


-- 
David Van Beveren                           INTERNET: emisle!dvb@ism.isc.com
EIS ltd. Professional Software Services     UUCP:   ..uunet!emisle!dvb
voice: (818) 587-1247

dvb@emisle.uucp (David Van Beveren) (04/26/91)

In article <1991Apr24.220616.254@emisle.uucp> emisle!dvb@ism.isc.com writes:
>
>I am trying to compile and link a test application, which is used to test a set
>of libraries being developed. The compile line is as follows:
>
>        cc -g -I. -I/usr/users/nova/include -I/usr/include/X11 -I/usr/include/Xm
> -D_NO_PROTO   -L/usr/users/nova/lib -L/usr/lib -L/usr/lib -L/usr/lib -o tst  ts
>t.o  -lScall -lScObj -lScDb -ladt -lbstr -lMem -lScall -lXm -lXt -lX11 -linet
>
>Partway into the link, I am receiving the following error:
>
>ld fatal: fail to write symbol name background_pixmap in string table for file t
>st
>*** Error code 13
>
>Error code 13 means Permission Denied. I assume the symbol table has gotten
>too big, like beyond the User-filesize limit. How do I change this limit to
>accomodate me? I tried compiling as root, and got the same result. What is
>the solution?
>
>System is ISC 2.0.2, dev system is ISC 2.0. 
>
>P.S. The file system being used has ~5MB free.
>
>

Thank you to ISC support email! (support@ism.isc.com)

I mailed this same message yesterday and got the answer today. The answer is
to increase the ulimit (which I suspected) Do this in /etc/default/login.
The ULIMIT=4096 line is now changed to ULIMIT=4096000 and it works fine. I
also got an acknowledgement of receipt of the other message, regarding the
compiler bug. I expect a reply soon. kudos.

Thanks guys. 
===
-- 
David Van Beveren                           INTERNET: emisle!dvb@ism.isc.com
EIS ltd. Professional Software Services     UUCP:   ..uunet!emisle!dvb
voice: (818) 587-1247

cpcahil@virtech.uucp (Conor P. Cahill) (04/30/91)

dvb@emisle.emisle (David Van Beveren) writes:

>Error code 13 means Permission Denied. I assume the symbol table has gotten

Error code 13 doesn't mean this.  However, you can only believe errno when
you have the source and see that the errno is being correctly reported.
The correct errno for attempting to write a file beyond the ulimit is EFBIG 
or 27.

>too big, like beyond the User-filesize limit. How do I change this limit to
>accomodate me? I tried compiling as root, and got the same result. What is
>the solution?

Quick solution: login as root, ulimit 99999, and then compile

Correct solution:  Read the FAQ for this group (question 12)

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

cpcahil@virtech.uucp (Conor P. Cahill) (04/30/91)

dvb@emisle.uucp (David Van Beveren) writes:

>I mailed this same message yesterday and got the answer today. The answer is
>to increase the ulimit (which I suspected) Do this in /etc/default/login.
>The ULIMIT=4096 line is now changed to ULIMIT=4096000 and it works fine. I
>also got an acknowledgement of receipt of the other message, regarding the
>compiler bug. I expect a reply soon. kudos.

While this does fix the problem, it is not the best way to do it.  Read
the FAQ.
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170