Bug 25943 - Options added to collect2
Summary: Options added to collect2
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.0.2
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-24 15:40 UTC by Perry Smith
Modified: 2013-11-10 20:03 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-04-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Perry Smith 2006-01-24 15:40:59 UTC
I have a number of things that I would like to see added to collect2.  If there is interest in them, I'll volunteer to do the work.  I am not sure of the process of making suggestions like this so if there is another format, please let me know.  e.g. I've put all of my suggestions into one report -- perhaps they should be split apart.

Changes to collect2:

1) Added the ability for collect2 to stop after the creation of the .c file which also implies an option to give the .c file a name.   Maybe:
	--c-file-only=foo.c
I would only add this to collect2's argument processing so to use it from g++, the user would do: -Wl,--c-file-only=foo.c

2) Same as #1 but with the object file.  Maybe:
	--o-file-only=foo.o

3) Right now collect2 looks at suffixes.  It would be nice to do one or both of the following two things:
3a) An option to add suffixes used for object files.  Maybe:
		--object-suffix=.32o
	to add the .32o suffix.
3b) Look at the magic number in the files to determine if they are an object file that needs to be looked at.  This could be an option as well.

The pitfall is that on AIX, an archive can have 32 bit object files and 64 bit object files (in the same archive) and the linker pulls out the ones it needs.  The way this is done usually is to have foo.c compile to foo.32o and foo.64o and then put all the object files into one archive.  gcc instead has path/libxxx.a and path/ppc64/libxxx.a  If the only difference is the 32/64 bitness, those could be combined.  This is what old farts like me are use to on AIX.

This system confuses collect2 in two places. If I do g++ foo.32o -o foo, collect2 never looks at foo.32o for constructors and destructors (or frame tables).  The trick I did was to put my object files into an archive and then collect2 scans them.  I am building a driver which means I need it in 32 bit form as well as 64 bit form.  I assume if I had both my 32 bit object files and my 64 bit object files in the same  archive, collect2 would scan all of them which is not the right thing to have happen.  collect2 could look at the magic numbers and resolve both of these short comings.  (collect2 knows if it is in 32 bit mode or in 64 bit mode.)

4) collect2 on AIX has two arguments that it passes to ld that can not be removed.  I'm wondering if those should be added in only if -nostdlib is not specified (or some other way to accomplish the same task).  There may be other flags to ld like this as well but I don't think so.  Right now, to get around this problem I have a script called ld in my path before the real ld and the script strips out the two arguments that I don't want.
Comment 1 Richard Biener 2006-01-25 10:48:30 UTC
The best way to address this is to try implementing this yourself and post patches.
Comment 2 Manuel López-Ibáñez 2012-04-17 21:47:21 UTC
No activity in 6 years, I would close as WONTFIX, but let's leave it at WAITING.
Comment 3 Andrew Pinski 2013-11-10 20:03:36 UTC
(In reply to Manuel López-Ibáñez from comment #2)
> No activity in 6 years, I would close as WONTFIX, but let's leave it at
> WAITING.

One more year so closing.