Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I have a two-fold problem at work, where I am trying to move the company's AIX 5.2 xlC-compiled C++ application to gcc (note that I just can't get binutils to work right, so I'm using the native linker. Anyone with experience using GNU toolchain under AIX wanna help with that one?). 1) The table of contents is > 64K, and according to their respective documentations, all options that either make the TOC bigger in ld, or put less in the TOC in gcc, make the program run slower. This is not desirable, but not a show-stopper. 2) A library of ours (tccommon) that we are linking in has classes that reference another class (status) in another library (tcdb). The application I am trying to link requires some classes from tccommon, but not any of the ones that require the status class. However, the linker is complaining that the status class is missing (undefine symbols) anyway. I thought they would have been garbage collected out. The xlC compiler has an option, "-qfuncsect", which puts each function in a separate csect. This seems equivalent to g++'s "-ffunction-sections". The kicker is that the older (for AIX 4.x) ld we used to use had an option "-qtwolink" to do a two-pass link to eliminate any sections containing only unreferenced objects. That killed both birds with two stones. The newer ld doesn't seem to have an equivalent option. My gut tells me there's nothing g++ can do about the problem, since g++ doesn't make any attempt to determine what objects get used or not, it just turns source code into objects. Is there some AIX ld option I can specify that I'm missing to tell it to not include parts of tccommon that are not used? Thanks. -- DDDD David Kramer david at thekramers.net http://thekramers.net DK KD DKK D Should you trust a stockbroker who's married to a travel agent? DK KD DDDD
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |