Failure of -lib, -pkg options

I am trying Critcl 0.34 on Linux/x86 (Fedora Core 4) with gcc 4.0.2 and binutils 2.15.94 Critcl works perfectly with this arrangement, if it is used with ::critcl::config combine "" (the default).

However, if either my Tcl source file or the critcl command itself supplies ::critcl::config combine with a different permitted value ("dynamic", "static" or "standalone"), then Critcl fails when it reaches the 'load' statement in critcl::cbuild and attempts to load gcc's output file. It appears that the -r option supplied to gcc does nothing at the compile stage, but is passed through to the ld linker and tells it to emit a linker object, not a shared library. 'load' fails when given such a file.

Possible workarounds require modification of the Critcl code, either to call critcl::cbuild without the 'load' option, or to supply gcc with different options (e.g. -shared instead of -r). The latter works with all possible values for ::critcl::config combine, and allows commands built with Critcl to be executed if they are appended to the Tcl source file.

If critcl is called with the -lib or -pkg options, then it fails with the "load" problem above, but neither workaround produces functioning libraries or packages. The plain critcl command with these options in the source:

  ::critcl::config combine ""
  ::critcl::config outdir .

does create a shared library that can be loaded by Tcl, and if it is substituted for the shared library produced by the critcl -pkg command, then the package works too, as long as the name of the shared library is unchanged.

It would not be hard to patch Critcl with the last workaround, which is sufficient for my own purposes. However, it would appear that some of the code that does not work with my gcc/binutils is there for a reason: for example the -lib and -pkg options use a "dynamic" build that emits a linker object, which is then used in the subsequent build (with different compiler/linker options) of the shared library.

I do not understand the reasons for calling gcc in this way - and I cannot be sure that my workaround would not break Critcl for users with other configurations - so I cannot supply a worthwhile patch.