Re: Linker ... still useful ?

guerin@IRO.UMontreal.CA writes:
>No, what I want to question in fact is linking as a process different from
>compilation, as a real step in the process of building executables.


As long as you'll have separately compiled parts of code, combined into
something new, you'll have a "linking" phase. It is definately different
from compilation.


>As a tool, linkers provide the ability to put together precompiled code.
>This permit to build much faster the executable than by recompiling all
>the source code, assuming the precompiled code not beeing modified.


Speed isn't really the only "raison-d'etre" I would say. Don't forget the
phases in a program's used to include a specific "loading" phase also. The
linker in modern systems also surfaces during this phase, linking the
executable to libraries which have been kept separate (dynamic linked libs)
until actually just before running.


>As a real step, linkers provide "implementation hiding" of used source
>code. Hence a company can furnish precompiled code without the user beeing
>able to figure out how the functionalities are implemented, assuming you
>don't want to reveal your secret trick ... Is this really the case ?? Is
>this really useful ??


Not only that. Libraries change. If you have to rebuild all packages with
each change youre in for a hell of a lot of work. If the library is dynamic,
and the interface has been kept the same, an update requires no more than the
replacement of 1 copy of the library. Maintainance person might get very upset
if you suggest upgrading all executables every time a library changes.


>As another real step, linker provide the ability to put together
>precompiled code from different source language. Especially useful when
>combining Assembler + High Lev Lang. But more and more HLL provide a way
>to put Asm code directly in the source code. Is there really an advantage
>to mix two HLL ? Even worst, many HLL don't provide the ability to be
>mixed because of the cryptic way they export their function name. This
>beeing because linkers are no more able to handle all the functionalities
>HLL want to.


Whoah! I would _never_ want to mix HLL with assembler. The former is
(hopefully) very portable, the latter is not. Mixing languages is a very
real thing if you consider distributed development, third party
components, etc, but you should not try to actually blend all languages
together. That will only get you into maintainance problems.


>Take a look at C++, implementation is definitely not as hidden as it could
>be, the language not hiding the private part of object, encouraging
>inlining, and template. Hence sacrificing implementation hiding to speed
>of the executable. Every company has its own way of encrypting function
>name so as to do type checking and overloading. C++ from X is even not
>linkable with C++ from Y.


Yeees, but then there are also examples where X and Y _are_ linkable. By
the way, here the linker _is_ getting more responsability, having to check
accross module typing. Call it name encryption, it is an added
functionality. Also you will want the linker to keep check on the template
generation, as doubles can be prevented/removed at link-time.


For languages like C++, it seems that linkers are no more than just tools.
On the HP-UX systems with the PA processor a linker is defintely more. It
compares the function call specification with the function header,
generating code to overcome differences. It also generates stubs for
inter-module calls, as may occur with dynamically linked/loaded modules.
And also it generates tables of addresses for dynamic procedure calls to
support Position independent code. And all this activity is _not_ related
to the language used.


>Now, the C++ community is bigger and bigger, So are other recent HLL
>community.


So what? the programming community as a whole is growing. COBOL is still
around...


>Hence, linkers are more and more just tools ...


Yes, but the question is if this is a desirable development.


>Is there still a place for linkers as real step toward the making of
>executable ???


I would say so. The cost of having to compile _everything_ when building a
program is simply to great, not to speak of the implications for
maintainance.


>Thanx for comment,
You're welcome.


>Frederic
>[It has always surprised me that what linkers do today is not much more, and
>in many cases less, than what they did 25 years ago. Perhaps the demands
>of C++ will make people think about what linkers can or should do. -John]
[I agree. There are numerous languages which are forced to move link-time
  work to compile time, simply because the linker won't/can't do it. C++ is
  an example. Modula-3 also. Module inter-consistency has to be double-checked
  at link-time; 'is this library the one I thought I would get...' -Bert]
--
    ------------------------------------------------------------------
    Bert Laverman, Dept. of Computing Science, Groningen University
    Email: laverman@cs.rug.nl Phone: +31-50-633948
    Home: bert@rakis.iaf.nl Fax: +31-50-633800
[Not mix assembler and HLL? I've done that lots, recode the time critical
parts into assembler on machines (Intel '86 notably) where that makes a
significant difference. -John]
--

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