The reality of working with safety/life-critical systems means it very dangerous for us to use shared libraries.

I understand the point about dependencies and the concerns expressed about extracting object files. But in my world the concerns are precisely opposite. It is safe to extract/use an object file (which can be properly controlled) and extremely unsafe to use a shared library (because other applications may "update" the library).

BTW, Extracting the objects from the library shouldn't matter. If the object files were created as expected, all external references/definitions that they need will be satisfied during the link phase. Besides, if the object files do have dependency problems the application will not link - which is much, much safer than the standard situation. In my world a change to a shared library automatically destroys application certification - and the change can make every application that uses that library dangerous to the public.

My problem right now is the dependency tree prevents the installation of "glibc-devel". However it looks like I can use the RPM "--nodeps" option to force Red Hat's "glibc-devel" package to install on my system. A better approach seems to be to use "rpm2cpio" (see http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html) to do the extractions. Has anyone tried this tool? If the "rpm2cpio" approach doesn't work we will probably have to force the install and handle the "glibc-devel" package like any other non-gpc library, see below.

To meet our safety requirements we will have to place copies of the 3 object files - and all other non-gpc items (shared files/libraries, tools, etc.) used to build the application - into non-shared (= non-standard) locations, then instruct the linker to look for these files in their new location. And everything involved (including all gpc components) will be placed under configuration control. The end result is that our installation of gpc would become "Stand-Alone" and immune to changes to shared software. This also seems to be the easiest way to make use of the "shared" files while still meeting our safety (and other) requirements. Critically for us, this approach also ensures that several years from now that nothing has changed and that we can recreate an absolutely identical executable of our application, starting from nothing.

The necessity to override standard locations with non-standard ones is another reason why it is important for gpc compiles to be separated into totally separate compile and link phases (e.g. two command files, normally invoked automatically, one after another). I suspect separating the gpc command into two separate compile and link command files is more complicated than just putting the commands (displayed by gpc -v) into separate files. For instance I don't see "hello.o" being passed to the "collect2" (the linker?) command and there also is the issue of how to handle/pass the temp files used by gpc.

Does anyone have any experience in doing this?

Thanks.

-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 27, 2010 05:04 PM To: GNU Pascal mailing list Subject: Re: GPC linker errors - help needed

On 27 Aug 2010, at 22:24, Morton, John wrote:

As expected "glibc.i686" was preinstalled. I tried installing the

i386

and x86_64 Red Hat rpms for "glibc-devel". Both rpms reported some unsatisfied dependencies. To make a long story short, in both cases

the

geometric growth of the dependency tree looks like it will eventually force all of the gcc C compiler to be installed. Maybe it's my non-C background but this hidden 3 file dependency (upon C) seems unreasonable given that all that gpc needs (see output below) is for those object files to be visible to the ld linker (assuming

these

object files are not dependent upon other files).

I would strongly recommend to simply install all dependencies. While things *may* work fine with just those files, they may just as well not for one reason or another. You can only make things more difficult for yourself by trying to circumvent the the dependencies of those packages.

Jonas