🚀 go-pugleaf

We would prefer to use gcc as our commercial production compiler.  This
is fine for executables, however, we also ship static and dynamic
libraries to our customers.  Our customers can't all use gcc to link.

In order to allow the customer to link gcc-compiled code with an
arbitrary linker, it seems we may need to ship the libarary. Are there
other options than these? 

 1. Ship libgcc.a as a separate file along with our libraries, and
    require our customer to link with it also. 

 2. Archive the libgcc.a into our libraries.

Option 1 complicates life for the customer by introducing another
library.  Option 2 might cause problems with version mismatch in the
event the customer has gcc different from ours.  Option 1 may display
this problem also.

We can't require the customer to link using gcc; they have their own
environments and requirements.  We have no problems supplying gcc to
them as a convenience, but if they want to use stock cc/ld or brand X we
must allow for it. 

The -fno-builtins switch does not completely remove lib dependence of
the generated code; there's still varargs and ___main, etc.

Any ideas?

Thanks,
---
Mitchell N. Perilstein          | mitch@clsi.com    | Ask about s/w patents
Compass Design Automation, Inc. | 410-992-5700 x225 | and interface copyrights.