GPC linker errors - help needed

Morton, John John.Morton at navcanada.ca
Wed Sep 1 22:57:58 CEST 2010


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 at gnu.de [mailto:gpc-owner at 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






More information about the Gpc mailing list