T.R | Title | User | Personal Name | Date | Lines |
---|
8870.1 | | QUARRY::neth | Craig Neth | Tue Feb 18 1997 10:30 | 3 |
| No, there is no way to do this. A .so is NOT like an archive - it is
a resolved object, not much different from an executable.
|
8870.2 | Maybe you can use the incremental linking options? | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Tue Feb 18 1997 10:59 | 0 |
8870.3 | | TAV02::JEREMY | | Thu Feb 20 1997 04:54 | 3 |
| Thanks for the replies. It looks like .1 is right, although it
seems terribly inconvenient for development environments with
huge numbers of objects.
|
8870.4 | | QUARRY::neth | Craig Neth | Thu Feb 20 1997 08:41 | 12 |
| >It looks like .1 is right,
Thanks. Since I work on the linker, I have this wild idea that I ought
to know such things :-)
> although it
> seems terribly inconvenient for development environments with
> huge numbers of objects
What you're asking for is an incremental linker. We'd like to do one, but
it would be a lot of effort, and to date, we haven't seen enough business
justification.
|
8870.5 | Larger number of smaller .so's... | DECC::SULLIVAN | Jeff Sullivan | Fri Feb 21 1997 15:11 | 18 |
| Re: .3
> seems terribly inconvenient for development environments with
> huge numbers of objects.
Maybe. But if that's the case, you probably want to break up your large archive
or shared object file into smaller pieces. Our project switched to using shared
object files for our development and debugging. We broke the big static archive
file into about 10 (logical) shared object files. This has worked great for us,
since the link times have significantly improved.
In the old world (one big static archive), incremental linking was high on our
wish list. With the new methodology, we don't really need an incremental linker.
We also build a debugging -non_shared executable, since we sometimes need to
copy it to another machine for debugging. When you need to do that, having to
copy all of the corresponding .so's can be a pain.
-Jeff
|