john@baldur.uucp (John Brinegar) (10/25/90)
I have been having problems with the linker under AIX V3.1 (RS/6000). It
seems that when linking a large executable (many libraries), the linker
eats up all paging space and the bind is killed by signal 9. This
occurs when the paging space size is 64 Mb (I have 32Mb of RAM).
By expanding the paging space to 144 Mb, the problem is resolved, but the
linker is still using between 80 and 90 percent of the paging space.
Needless to say, this brings the entire machine to a near standstill due to all
the swapping going on, and links of this executable take much, much longer
than they should (~40 minutes).
IBM has supposedly fixed some problems with the linker in the 3001 update
(July update), but I installed this update and ran into the exact same problem.
Has anyone experienced any similar problems with the linker (bind) on this
system? Is the linker really that much of a memory hog, or do I have something
configured wrong? Any help with this problem is appreciated.
John Brinegar {att!uswat, uunet!dunike} !onecom!john
TelWatch, Inc. (303) 440-4756
--
John D. Brinegar {att!uswat, uunet!dunike} !onecom!john
TelWatch Inc. (303) 440-4756 peter@msinc.msi.com (Peter Blemel) (10/26/90)
In article <1990Oct25.024421.7418@onecom> john@baldur.uucp (John Brinegar) writes: > >I have been having problems with the linker under AIX V3.1 (RS/6000). It >seems that when linking a large executable (many libraries), the linker >eats up all paging space and the bind is killed by signal 9. While never having encountered this manifestation, I am plagued by another mean nasty bug. When linking large executables, the linker starts to claim that symbols are undefined when in fact they were defined the last time I linked the code! If I swap the order of the objects different objects become undefined while previously undefined objects are now okay. This happens in my fortran code as well as C code, but mostly occurres when linking code that uses a lot of symbols (like X11 stuff). I can make it go away (sometimes) by just #including all of the code in one file. Yick. Machine : 520, 48mb ram, 128mb paging space, 3001 update applied. Peter
rudy@chukran.austin.ibm.com (/50000) (10/30/90)
In article <129@.msinc.msi.com> peter@msinc.msi.com (Peter Blemel) writes:
While never having encountered this manifestation, I am plagued by another
mean nasty bug. When linking large executables, the linker starts to claim
that symbols are undefined when in fact they were defined the last time I
linked the code! If I swap the order of the objects different objects become
undefined while previously undefined objects are now okay.
I'd suggest trying the additional flag "-b nodelcsect" on your links.
This often makes those nasty unresolved symbols "go away". Lets
just say that this flag should be the default, but it is not
currently. A rule of thumb is that if your link involves duplicate
symbols, then this flag will probably help.
--
*********************************************************************
Rudy Chukran | EMAIL: | Voice:
IBM AIX Porting Center | RSCS: CHUKRAN at AUSTIN |512-838-4674
11400 Burnet Rd. | AWDnet: rudy@chukran |Tieline: 678-4674
Internal ZIP 2830 | |
Austin, Texas 78758 | |
*********************************************************************bengsig@oracle.nl (Bjorn Engsig) (10/30/90)
Article <1990Oct25.024421.7418@onecom> by john@baldur.uucp (John Brinegar) says: | |I have been having problems with the linker under AIX V3.1 (RS/6000). It |seems that when linking a large executable (many libraries), the linker |eats up all paging space and the bind is killed by signal 9. Frequent readers of this group will know that the linker on AIX 3.1 is using extreme amount of paging space. It also does much more for you than other Unix linkers, like solving all references at once by having a complete symbol table of all libraries. -- Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl ORACLE Corporation From IBM: auschs!ibmchs!cs.utexas.edu!uunet!oracle!bengsig "Stepping in others footsteps, doesn't bring you ahead"
madd@world.std.com (jim frost) (11/06/90)
bengsig@oracle.nl (Bjorn Engsig) writes: >Article <1990Oct25.024421.7418@onecom> by john@baldur.uucp (John Brinegar) says: >| >|I have been having problems with the linker under AIX V3.1 (RS/6000). It >|seems that when linking a large executable (many libraries), the linker >|eats up all paging space and the bind is killed by signal 9. This is correct. In a different article someone asked if the 3001 patch corrected the problem. It does not. We haven't applied the 3002 patch yet. >Frequent readers of this group will know that the linker on AIX 3.1 is using >extreme amount of paging space. It also does much more for you than other >Unix linkers, like solving all references at once by having a complete symbol >table of all libraries. This isn't so much a function of their linker as of their linking conventions. The conventions allow shared libraries to be linked in without paging in very much of the executable you're linking, allowing for very fast startup times for executables which use shared libraries. The TOC linking convention is very elegant, but it does have its limitations. You cannot have, for instance, more than 2^14 (16384) global symbols (TOC table entries -- one TOC per global variable or global function) per function. As of the 3001 update (and I believe 3002) the linker cannot build more than one TOC per a.out, effectively limiting programs to 2^14 global symbols. This is a surprisingly low number given the effort that went into supporting large executables on the RS/6000. I have received no word on whether or not they plan to correct this deficiency. jim frost saber software jimf@saber.com
tif@doorstop.austin.ibm.com (Paul Chamberlain) (11/06/90)
madd@world.std.com (jim frost) writes: >bengsig@oracle.nl (Bjorn Engsig) writes: >>... the linker on AIX 3.1 is using extreme amount of paging space. >... limiting programs to 2^14 global symbols. This is a surprisingly low >... [I don't know] whether or not they plan to correct this deficiency. Please don't ask them for new linker features unless you have several gigabytes of dedicated paging space. 1/2 :-) Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
luis@mavrick.UUCP (luis basto) (11/09/90)
> >| > >|I have been having problems with the linker under AIX V3.1 (RS/6000). It > >|seems that when linking a large executable (many libraries), the linker > >|eats up all paging space and the bind is killed by signal 9. > > This is correct. In a different article someone asked if the 3001 > patch corrected the problem. It does not. We haven't applied the > 3002 patch yet. > If this is the same problem I believe I'm thinking about, then it's fixed in the 3003 update. 3002 is not officially shipping yet and I won't even attempt to guest a date for 3003. -- Luis Basto Work: (512) 823-3081 Usenet: ...!cs.utexas.edu!mavrick!luis
madd@world.std.com (jim frost) (11/09/90)
luis@mavrick.UUCP (luis basto) writes: >3002 is not officially shipping yet and I won't even >attempt to guest a date for 3003. My 3002 release is dated Oct 18. We got it shortly after that date. If 3003 is the `November performance release' (it used to be the `October performance release' but IBM is beginning to sound like NeXT) then you should expect to see it within 3-4 weeks, although I'm betting on the first of the year. jim frost saber software jimf@saber.com
shawn@jdyx.UUCP (Shawn Hayes) (11/10/90)
I guess we will all have to call up and ask for the latest release when it becomes available. I wish IBM would at least ship out notices of the latest bug fixes. It's kind of disturbing to have my SE come by and say that I need to get the latest update to fix a problem that will occur on certain dates just a few days before the problem should show up. Then I get the software and find out the update has been available for almost a month.. I'll admit that most other companies are no better and some are much worse. That still doesn't help us out. Maybe if we all keep asking they might decide to send out notices when a new update becomes available. Shawn Hayes