Re: Egcs for AIX

[Andrey Slepuhin <pooh at msu dot ru>]

On 21-Apr-99 Carsten Griwodz wrote:
> David Edelsohn wrote:
> [...]
>>      AIX executables bind imported symbols to particular shared objects
>> by name.  Changing the name of the shared object prevents the executable
>> from telling AIX the proper library to load.  I presume that you compiled
>> libstdc++.a as a shared object.  The -brtl flag causes AIX to act more
>> like SVR4 and find symbols by name from libraries in the LIBPATH instead
>> of particular shared objects. 
> 
> Yes, my libstdc++.a is a shared object, libstdc++-ar.a is not. I renamed
> libstdc++.a to check which of my binaries were statically linked. I had
> not really understood the effects of -brtl, thanks for the info.
> 
> [...]
>>      If you have suggestions on how to improve collect2 on AIX, I would
>> be happy to consider patches.  What aspects of collect2 did you change to
>> obtain the improvement in executable size?
> 
> The reduced executable size is a side-effect. I tried to get executables
> that are truly stand-alone which did not work with the original
> distribution.
> 
> For this, I pass the original command line from g++ to collect2 (using an
> environment variable). If there is no shared object on the command line
> (nor something like -Wl,-brtl), I replace libstdc++ with libstdc++-ar
> and don't add the import file to the ld call. The result is an executable
> that is truly stand-alone.
> An unverified alternative idea is to drop the -bI:file and to add -bstatic
> in front of -lstdc++.

To receive a truly stand-alone executable, you *only* need to pass -static
to g++. This will create executable which doesn't depend on *any* shared
library. But if you only need to link libstdc++ statically you may
pass -Wl,-bstatic -lstdc++ -Wl,-bdynamic to g++. Be sure that all
linked shared libraries do not depend on libstdc++. -bI: flag doesn't
refer to your problem.

> I am not generating additional code for the constructors and destructors
> of shared objects in this case, either.
> 
> The reduced code size is a result of putting more symbol names into the
> import file.

I am worrying about small code size of executable. Normally, a size
of unstripped C++ executable should be >160Kb. This is because
an executable includes many things from libgcc.a. Shared libraries
are not linked with libgcc.a, they instead linked with import file
which points that appropriate undefined symbols should be resolved
from main executable. This trick is needed to guarantee *unique*
copy of some static symbols in libgcc.a in executable.

> When the target object is not shared, but an object examined by
> scan_prog_file() is shared, I put symbols that are in the undefined
> symbols list into the import file.
> This seems to save on libgcc.a in particular; a lot of symbols from
> libgcc.a are requested by libstdc++.a because undefined symbols from
> shared objects are put into the undefined list in scan_prog_file().
> I guess this was also intended by use_import_list() but it didn't
> seem to have any effect in my environment.

use_import_list() now is used only to generate import list for libgcc.a.
May be it is useful to link with import list instead of actual library
in other cases - I don't know. 

Regards,
Andrey.