Peter N Lewis wrote:
Is there any way to combine .o files together to form a single object file that can still be linked in?
The reason I'd like this is that the Mac interfaces are made up of about 350 units, and each of them produce a .o file containing the init code (even though there is no implementation section). As far as I'm aware, there is no way to make GPC not produce the implementation code or not call it. I thought that if I called it like:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
I obviously can't add /Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces/*.o to the end because the command line would be way longer than allowed.
This might be a reason why the above doesn't work since it's also passed on the command-line.
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood), and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
300000 lines sounds very much. It's more than on my Linux system the total of all headers of the system, X11 various libraries etc.
I don't know what all this stuff is, but if it includes all those things, it might be useful (also for the user) to split it according to functionality ("real" system, GUI, etc.) and make it one or a few units each.
This doesn't mean that GPC will necessarily fail on such a large unit (I haven't tried this, except for pathetic cases). If there are no O(n^2) cases anymore, it might work, but it might take a lot of memory ...
Frank