Frank Heckenbach wrote:
Adriaan van Os wrote:
gp program.pas = gpc --automake -o program program.pas gp unit.pas = gpc --automake -c unit.pas
The latter brings me to the following for gp (see gp --help)
-c Compile only, do not link (default if main source file is a unit or module rather than a program)
As far as I know, the opposite switch is not available, namely to compile *and link* a unit. This is useful when compiling a unit into a shared library, while still using the specs file instead of a separate ld run (which could be less compatible).
Compiling to shared libraries requires more options. A simple compilation without `-c' won't do. So it's more involved than adding a switch.
For one thing, it requires all files to be compiled with `-fPIC' (position independent code). This might not be necessary on all targets, and the option may even be called differently on some, but in general this means compiling everything twice, so that static libraries don't incur the (slight) performance penalty of PIC.
Then, on Linux, I need options such as
-fPIC -shared -Wl,-soname=foo.so.1.2.3
The latter is required so if the library is linked to foo.so (as usual), and this is used for later linking in a program, the linker knows that the real name is foo.so.1.2.3, so it will use the correct version even if later another version was installed and linked to foo.so. (That's an important point of shared library version management.)
AFAIK, the libtool authors have spent quite some time (and not really all too successfully, IMHO) trying to automate this across platforms. Perhaps it will actually be somewhat easier to do in gp (which does the compiler invocations anyway) than in libtool (which needs to wrap all compiler invocations in a script, with its own set of problems). But still expect quite a bit of work and testing ...
Of course, I can write a patch for gp to add this feature. Any suggestions for the switch to use ?
Certainly a long name as there are already so many short names, and we should allow for future additions in the backend (as far as they'll make sense with gp). Perhaps something like `--create-shared-library=foo.so.1.2.3'. But that's really the least problem.
An option --create-shared-library would be nice, of course, but I understand that it can be a problem, at least across platforms. So, I were really only thinking of sending in a patch that implements a --compile-and-link option that overrules the automatic -c option for units, that's all (a five minute hack).
Given that option, It is no problem to create a dynamic library on Mac OS X with Darwin specific compiler options, like -dynamiclib (see <http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Darwin- Options.html#Darwin-Options>). I checked this morning that gpc can actually create a dynamic library with one call (!). Through the specs, gpc invokes libtool and it creates the dynamic library (there was indeed a problem left but that's another issue that I still have to look at).
With gp, this is currently impossible, because of the automatic -c for units (which I agree is a good thing to have as default).
Regards,
Adriaan van Os