Re: linking problem
Re: linking problem
- Subject: Re: linking problem
- From: Greg Guerin <email@hidden>
- Date: Fri, 6 Jul 2007 12:22:01 -0700
mark wrote:
>But linking against the stub causes it to link against the "wrong"
>'activeView' variable (stub's address are different form
>application's).
Maybe I'm missing something, but if the stub's addresses differ from the
real app's, that seems intrinsically broken to me.
If a stub library has different addresses than the real library it's
supposed to be substituting for, then the stub is fundamentally
inconsistent with the real library. And if a stub is inconsistent with the
real library, then linking against the stub is not equivalent to linking
against the real library. To the code being linked, it's as it they were
two separate versions, or even two separate things.
With all the missing symbols you get when linking against the app itself,
vs. none when you link against the stub lib, are you sure that the stub,
the app, and the plugin have the same usage of two-level namespaces, i.e.
all enabled or all disabled?
The only other thing I can think of is that the stub might be single-arch,
while the app is multi-arch, or has a different arch than what the stub
has, or something else related to archs is weird (64 vs 32 bits?). The
linker will not mix architectures: it needs to link against the same arch
as the thing being linked from.
>The defined symbols are DEFINITELY being exported by the application
>(development build) as 'nm' shows it.
>I need to link against the stub to prevent these errors.
If you're linking against the app itself, that should resolve the symbols.
If it doesn't work and you then link against the stub, that sounds like
you're doing something that causes the symptom to disappear (unresolved
symbols are resolved), but doing so fails to address the real problem: why
the plugin won't link against the hosting app it's supposed to be plugging
into.
To me, the most fundamental problem is that linking against the app itself
should resolve the plugin's symbols, but it doesn't. If it doesn't, then
you need to investigate why that is happening. If you paper over that
problem by then linking against the stub, then that makes the link work,
but obviously doesn't address the real problem, which is why linking
against the app itself doesn't work.
Again, I could be missing something, because you don't say how the stub
library came to exist, nor it's relationship to the actual app. But it
seems to me that the linker is trying to tell you about an error
(unresolved symbols linking against the hosting app), which cannot be
properly solved by linking against a stub, especially if the stub and the
app are inconsistent with one another, as they seem to be.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden