forcing link errors

fjh@cs.mu.OZ.AU (Fergus Henderson)
13 Mar 1998 00:04:44 -0500

          From comp.compilers

Related articles
forcing link errors fjh@cs.mu.OZ.AU (1998-03-13)
| List of all articles for this month |

From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.compilers
Date: 13 Mar 1998 00:04:44 -0500
Organization: Computer Science, The University of Melbourne
Keywords: linker, question

Our compiler generates C, which is then compiled to object code. Some
of the compilation options can affect the generated code in ways that
break binary compatibility. I'm looking for a way to ensure that if
the user tries to link files compiled with different options then they
will get a link error, not a run-time error. Furthermore, I want to
be able to do this using the system linker, rather than by writing our
own pre-link pass.


I have in fact succeeded in this task, except that my solution doesn't
work in the case of shared libraries. My solution is for each
generated .c file to include a reference to a constant `grade_<foo>',
where <foo> is an encoding of the compilation options. This constant
is defined in the runtime library. (We compile a different copy of
the runtime library for each different "grade".) If a file is
compiled in grade <foo1>, and then linked against the runtime library
for grade <foo2>, then the result is an undefined symbol error for
`grade_<foo2>'.


That still doesn't catch the case where the user somehow tries to link
in two different versions of the runtime library. (The difficult with
making things fool-proof, of course, is that fools are just too bloody
clever ;-). So to catch that case, the object file in the runtime
library which contains the definition of `grade_<foo>' also has a
definition of another symbol `library_grade'. If the user links in
multiple versions of the runtime library, then the symbol
`library_grade' will be multiply defined.


That all works fine with static libraries. The problem comes when you
use Unix shared libraries. It seems that the various Unix system
linkers that I have tested (namely the ones on Linux, Digital Unix,
and Solaris) do not even warn about multiply defined symbols if the
extra definition(s) occur in shared libraries.


Is there any (preferably portable) way of forcing a link error in
cases like this?


--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.