3 ms·

gcc -shared -o mycrypto.1.1.so file1.c file2.c file3.c file4.c #include "mycrypto.1.1.h" Doesn't that have the same effect of being easy to include? The amalg

gcc -shared -o mycrypto.1.1.so file1.c file2.c file3.c file4.c #include "mycrypto.1.1.h" Doesn't that have the same effect of being easy to include? The amalgamation may be better for the compiler but I'm not sure why.

tialaramex 8y ago
A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work. But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster. Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.
- tedunangst 8y ago
  The compiler invocation above only creates a single object file.
  - tialaramex 8y ago
    No, but I can see why you thought so. The invocation above creates one object file for each C source file, as temporary files, (in a Unix system you can watch it do this with a suitably powerful syscall tracer, presumably something similar is possible on non-Unix systems but I don't know exactly how) Then it links them and produces the output you've mistaken for an "object file", then it deletes the temporary files.
    - tedunangst 8y ago
      Ah, probably the easiest way to deal with some translation unit edge cases. :(
CJefferson 8y ago
Now do it on Mac, and windows, and dynamic and static, and install the libraries in the right place. It gets maddening.

tialaramex 8y ago

A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work. But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster. Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.

tedunangst 8y ago
The compiler invocation above only creates a single object file.
- tialaramex 8y ago
  No, but I can see why you thought so. The invocation above creates one object file for each C source file, as temporary files, (in a Unix system you can watch it do this with a suitably powerful syscall tracer, presumably something similar is possible on non-Unix systems but I don't know exactly how) Then it links them and produces the output you've mistaken for an "object file", then it deletes the temporary files.
  - tedunangst 8y ago
    Ah, probably the easiest way to deal with some translation unit edge cases. :(

CJefferson 8y ago

Now do it on Mac, and windows, and dynamic and static, and install the libraries in the right place. It gets maddening.