Can I dynamically link a library with static initialization code?

  • Thread starter Thread starter Hurkyl
  • Start date Start date
Click For Summary

Discussion Overview

The discussion revolves around the issue of linking object files and libraries in a UNIX environment, specifically focusing on the behavior of static initialization code in a library context. Participants explore the implications of static versus dynamic linking and how it affects the execution of initialization routines.

Discussion Character

  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant describes a scenario where static initialization in a hidden object file (private.o) does not execute when linked as a library.
  • Another participant suggests using the `-static` option to include the library's code in the executable, implying that this may resolve the issue of static initialization not being called.
  • A third participant expresses unfamiliarity with the `-static` option and indicates willingness to look it up for further understanding.
  • There is a suggestion to try linking with the `-static` option to see if it resolves the problem, but no confirmation of its effectiveness is provided.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the solution, as the effectiveness of the proposed `-static` option remains untested and uncertain.

Contextual Notes

The discussion does not clarify the specific behavior of static initialization in the context of dynamic versus static linking, nor does it address potential dependencies or assumptions related to the linking process.

Hurkyl
Staff Emeritus
Science Advisor
Gold Member
Messages
14,922
Reaction score
28
Here's my (UNIX) situation.

I have three object files:

program.o
public.o
private.o


public.o is "standalone" -- it is entirely self-contained.

program.o refers to functions defined in public.o

private.o is "hidden" -- neither program.o nor private.o make any reference to anything contained in private.o. However, private.o contains some static initialization that calls functions in public.o. (Essentially registering itself with the features that public.o provides)


Linking them together is no problem. I simply do:

g++ program.o public.o private.o

and a.out does exactly what I expect it to do.


Then, I tried a variation. I put public.o and private.o into a library. I think the command was

ar crsu libtest.a public.o private.o


Now, I link program.o with this library

g++ program.o -L. -ltest

This doesn't work, because private.o's startup code is never executed.

I also tried

g++ program.o libtest.a

and got the same result.



Can I do anything to have this all behave like I want? (But without having program.o or public.o reference anything in private.o?)
 
Technology news on Phys.org
Have you tried using -static?

- Warren
 
I'm not familiar with that option. I can look it up in the man page, if you don't want to explain it further.
 
Static linking means you want to include the library's code inside your executable. The alternative is dynamic linking, where you leave the code in the library, and reference it only at runtime. I suspect that if you don't compile your library statically into your executable, the static initialization code never has any reason to be called.

Try `g++ -static program.o libtest.a` and let me know what it does.

- Warren
 

Similar threads

  • · Replies 12 ·
Replies
12
Views
4K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 15 ·
Replies
15
Views
5K
  • · Replies 17 ·
Replies
17
Views
3K
  • · Replies 8 ·
Replies
8
Views
3K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 5 ·
Replies
5
Views
2K