help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared versus archive library


From: Paul Pluzhnikov
Subject: Re: shared versus archive library
Date: Tue, 01 Nov 2005 09:47:09 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)

"Greg" <greg.szeszko@tradingtechnologies.com> writes:

> It appears that in fact the symbols from the object file containing
> unresolved references are not used.  

I told you so :)

> I recompiled all of source files with -ffunction-sections and
> -fdata-sections. 

This couldn't possibly fix your problem: the functions *are* used
by some executables, so they must be part of the DSO.

You are trying to program by coincidence:
  http://www.informit.com/articles/article.asp?p=31538&rl=1
instead of taking the time to understand the problem.

> When make got to linking against static libraries,
> the linker died with the following message:
>
> /usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at
> ../../bfd/elf32-i386.c line 2262 in elf_i386_relocate_section
> /usr/bin/ld: Please report this bug.

Well, you've found a bug in BFD. In order to report this bug,
you'll need a reduced test case (which so far you've resisted
producing :(

> Is there anything else that you can advise me to do to make the .so
> libraries run?

Yes: spend the time producing a small test case, so we can all
understand the problem. Once the problem is understood, the solution
will likely trivially follow.

It's usually not that difficult to make a small test case:

Begin with "int main() { return 0; }", linked against one of the
libraries you are having problems with (let's call it foo.so). 

Does this fail?
If yes, 
  re-link foo.so, eliminating some of the objects from it.
  Continue removing objects until it starts to run.
  Reduce the problem to a single "problem" object.

  Now reduce the problem more by eliminating parts of the object
  (by removing parts of source).

  I expect you'll have a trivial test case in under an hour.

If no,
  your entire premise is suspect: you said you didn't call into
  functions that need the missing callbacks, but clearly you need
  to call *something* from foo.so to trigger the failure.

  In this case, you'll want to run your exe under debugger,
  set a breakpoint on _dl_signal_error() and see what stack trace
  triggers that breakpoint.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]