Hi!

In our company we have a big c++ software project devided into several
shared object libs. several programs link particular so's to
executables.

my question is: assuming that the .h files don't change but only the
..cpp files and maybe some compilerflags: is it necessarry to re_link_
the executables after building a new .so file?

Thanks!
Sebastian

Sebastian Wagner <s.wagner@gmx.at> wrote:

: In our company we have a big c++ software project devided into several
: shared object libs. several programs link particular so's to
: executables.

: my question is: assuming that the .h files don't change but only the
: .cpp files and maybe some compilerflags: is it necessarry to re_link_
: the executables after building a new .so file?

Typically, no. But if your compiler flags somehow affect interface
(for instance you've changed 32-bit compilation to 64 bit, or redefined
some macro which affects .h files) you'll need to relink. 

-- 

> Typically, no. But if your compiler flags somehow affect interface
> (for instance you've changed 32-bit compilation to 64 bit, or redefined
> some macro which affects .h files) you'll need to relink. 

the point is: can relinking _only_ fix the problem - or do I need to
compile the other sources _anyway_ e.g. in the 32/64 bit example which
implies that I could link two different object files with different
compiler options into one. That doesn't really make sense, doesn't it?

sebastian

Sebastian Wagner wrote:
> Hi!
> 
> In our company we have a big c++ software project devided into several
> shared object libs. several programs link particular so's to
> executables.
> 
> my question is: assuming that the .h files don't change but only the
> .cpp files and maybe some compilerflags: is it necessarry to re_link_
> the executables after building a new .so file?
> 

Linking to a .so just resolves references to symbols that are used by 
the program (or other libraries).  So if your new .so build doesn't 
change or remove any of the symbols that the program (or other .sos) 
resolved when it was linked then the program will execute without 
relinking.

For example, you could build a skeleton version of an API what does 
nothing (i.e. stubs) but can be built to a .so.  Then you could link 
programs against that .so containing stubs.  When you replace the stub 
version with a fully implemented version the programs will run, no 
linking necessary.

Of course, if you change the interface to the .so from what it was when 
the program was *compiled* then it will still run but unpredictable 
results can be predicted.

-- ced


-- 
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

Hi Chuck,

thanks so far. I'm aware that linking just means resolving symbols.
And as far as I know, compiling with C should work that way. I heard
that compiling so's in C++ could affect the so's because C++ with gcc
changes the interface names to a mixture of the class name and
function, so there can be an explicit resolvement of the specific
function that is called.
Now, the question: touching for example the source file (without
changing _any_thing) and recompile the so with _other_ gcc switches
can change the interface. Thats the assumption - which would be crab,
of course. Is that correct? And if yes, what can you do to prevent
that?

Sebastian


Chuck Dillon <cdillon@nimblegen.com> wrote in message 

> Linking to a .so just resolves references to symbols that are used by 
> the program (or other libraries).  So if your new .so build doesn't 
> change or remove any of the symbols that the program (or other .sos) 
> resolved when it was linked then the program will execute without 
> relinking.