These are extremely practical tips on using binutils to shrink your libraries. It might also be worthwhile to compile the library without per-function sections in the first place, which hopefully can be done without patching rustc. On many platforms this produces significantly smaller code in GCC.
I'd be very surprised if the C/C++ code being written today was comparable in volume to the collective pile of JavaScript, Java, C#, Go, Python, and PHP.
Contrast to the heyday of C and C++ when not much else got a look in (Pascal perhaps? Perl probably...)
Sure, but I think that "back in the day your compiler would ..." is a reasonable characterisation.
Back in the day, yes, your compiler almost certainly would do that. Now, your compiler might possibly do that. For most working stiffs it won't though.
hmm how can I reuse this useful Go library in python... Oh I can't.. hmm and how can I reuse this useful java library in php ? Oh I can't. Oh and which of the programming languages you mentioned can and do use C libraries? All of them.
Reminds me of that coworker who thought that OpenCV was basically written in python.
I'm not claiming that there is no C or C++ out there. But it's such a nit pick when for most developers, no, their day-to-day work absolutely does not involve the creation of object files.
Sure, akshuwally, there are still C and C++ devs out there. Meanwhile a friend has just embarked upon a career as a pro COBOL developer. What of it?
Edit: Also, in the spirit of akshewally, I have just googled up this monster! My word, PHP and Java AND XML... it's like the unholy trinity of HackerNewsbane... https://php-java-bridge.sourceforge.net/pjb/
> A static library is nothing but a bundle of object files, wrapped in an ancient and never-quite-standardized archive format.
To this day I'm astonished that it's not just tar. Or pax. Or even cpio! Or literally any file format that has any other use.
These are extremely practical tips on using binutils to shrink your libraries. It might also be worthwhile to compile the library without per-function sections in the first place, which hopefully can be done without patching rustc. On many platforms this produces significantly smaller code in GCC.
> Back in the day, your compiler or assembler would turn each source file into an “object” file containing the compiled code.
Lots and lots of code is still C and C++. That's not really "back in the day".
I'd be very surprised if the C/C++ code being written today was comparable in volume to the collective pile of JavaScript, Java, C#, Go, Python, and PHP.
Contrast to the heyday of C and C++ when not much else got a look in (Pascal perhaps? Perl probably...)
I think it's fair.
Yes, surely much more code is being written in other languages than in C, but probably more C is being written now than ever before, too.
Sure, but I think that "back in the day your compiler would ..." is a reasonable characterisation.
Back in the day, yes, your compiler almost certainly would do that. Now, your compiler might possibly do that. For most working stiffs it won't though.
Ok, my side of the shed's painted now :D
hmm how can I reuse this useful Go library in python... Oh I can't.. hmm and how can I reuse this useful java library in php ? Oh I can't. Oh and which of the programming languages you mentioned can and do use C libraries? All of them.
Reminds me of that coworker who thought that OpenCV was basically written in python.
I'm not claiming that there is no C or C++ out there. But it's such a nit pick when for most developers, no, their day-to-day work absolutely does not involve the creation of object files.
Sure, akshuwally, there are still C and C++ devs out there. Meanwhile a friend has just embarked upon a career as a pro COBOL developer. What of it?
Edit: Also, in the spirit of akshewally, I have just googled up this monster! My word, PHP and Java AND XML... it's like the unholy trinity of HackerNewsbane... https://php-java-bridge.sourceforge.net/pjb/