Re: how to get "the big picture" with nm, objdump, size for object size?

[Ilya Murav'jov <muravev at yandex dot ru>]

Cary Coutant ÐÐÑÐÑ:
>> Obviously, ar & ranlib slow down the most because of much debug stuff
>> (44Mb vs. 10Mb). So, the "solution" is just to avoid intermediate static
>> libraries (they are evil) and always feed object files directly to
>> linker (even if one need to build several executables/shared_libs from
>> the same sources - for developing, "cook" them directly from object files).
>>  I have the immediate effect as -6 sec to a build. :)
> 
> You could try thin archives (see the ar 'T' option). They let you
> continue to use archive libraries as usual, with the link-time
> behavior unchanged, without paying the price for copying the whole
> object files into the archive.
> 

Thanks, it solves the problem too. But in my case I have to do symbolic
links of some static libraries, so linker cannot find original object
files, like so:
$ ar rcT build/libs/mpeg2dec/libmpeg2/libmpeg2.a decode.o header.o ...
$ ranlib build/libs/mpeg2dec/libmpeg2/libmpeg2.a
$ cd build/lib && ln -s ../libs/mpeg2dec/libmpeg2/libmpeg2.a
$ g++ -o build/mgui_tests -Lbuild/lib -lmpeg2 ...
/usr/bin/ld: error: cannot open build/lib/decode.o: No such file or
directory
/usr/bin/ld: error: cannot open build/lib/rgb.o: No such file or directory

Could that be considered as a bug? :)

Regards,
 Ilya