Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!unmvax!bbx!yenta!msinc!peter
From: peter@msinc.msi.com (Peter Blemel)
Newsgroups: comp.unix.aix
Subject: Linker heartburn in 9021
Message-ID: <107@.msinc.msi.com>
Date: 17 Aug 90 00:14:15 GMT
Organization: Management Sciences, Inc.
Lines: 61
References:

System: 520, AIXV3.1 9021, 64mb ram, 1.2 gb disk., page/swap=64mb

   Our programs have been increasing rapidly in size as our development effort
moves along. This problem first manifested itself during Motif development, but
soon it became obvious that most sizeable programs are affected.

Scenario:
1) A C program compiles and links fine, producing a rougly 2mb executable. This
is a mindless X-Windows front end to a fortran program, but being compiled 
stand-alone with c-stubs for the fortran modules. Minor additions to the
program (in the most recent case, a single assignment statement was addedd)
result in the linker complaining about unresolved externals in unrelated modules
that were not changed or recompiled. The modules it declares to be undefined
are all callbacks (not directly called), but all have been declared "extern
void foo()" before they are referenced. I tried removing the "extern" from the
statement, but this had no effect.

2) A FORTRAN program compiles and links fine, producing a roughly 3.5 mb exec. I
am trying to put a C X-Windows front end on it (Namely the program in #1). When
I try to link it with the C program above (having corrected for the main()s),
none of the C routines are unresolved (even though they remain unresolved if
compiled stand-alone), but the linker complains about several of the fortran
functions being unresolved.

Things I've tried to date:
Rearranging the order of the objects in the link command. Some modules become
resolved, others become unresolved. Certain modules will never become
resolved, although I can not see a connection here.

I thought perhaps the system limits for filesize and memoryuse were choking
the linker (I.e. temp files were too large), so I raised the limits via
smit's user's menus. See the side notes below about this fiasco. No effect on
the link problems. 

I put the objects in question into an archive and I ranlib'd them. No effect
(tried cc -o prog libfoo.a , and cc -o prog -L. -lfoo).

I tried putting all of the files into on BIG archive, different modules are
unresolved, but reproduceably so (I get the same ones twice in a row).

Any ideas???

The limit's fiasco:
I reset the limit's on the uid's having the problems, but I decided that I 
really don't like limits, and especially not the default ones (I HATE having
a huge job run for hours and then crap out because its temp files were 
getting large (tar, for example). So, in the smit menu, I put 0's into the
fields (I tried leaving them blank, but then the values in question were set
to default, not unlimited). Typing limit at the csh prompt reports "unlimited"
on everything. The side effects of this are nasty. I can not ftp into my account
becuase ftp says "can't get resource limits" after prompting me for a password.
rsh has problems, but gives no messages (just dies, having done nothing). 

How does one go about getting unlimited resources?

---------------
Peter Blemel
Management Sciences, Inc.

This uucp path is known to be extremely flakey (We're changing software at the
present time), so any email replies need to be sent to msinc@jupiter.nmt.edu.