calling from one libfoo.a to another

calling from one libfoo.a to another

[travis]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Hello all,

Not sure where to ask this, apologies in advance if this isn't
appropriate.  I'll only ask once, so ignoring me or a direct response
will be sufficient.

I'd like to call from one library (libfoo.a) to another (libbar.a) without
directly linking the two.  In other words, I'd like to have the symbol
resolved when I link the final executable.  I've tried "weak"
attribute, and they work in some cases, like when the caller is not in
a library, but on our platform, when you compile it into libraries, it
gets left undefined... a call to the weak reference will segfault at
run-time (I assume because it's not getting defined before the

I'm just curious if there's an easy way to call from one .a to another
to avoid drastically restructuring our code base.

If this is unclear, please let me know.
-- 
A Weapon of Mass Construction
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john@subspacefield.org to get blacklisted.

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: calling from one libfoo.a to another

[Brian Budge]

I'm not sure I understand.  I believe that in the past I've done what
you're talking about without issues.  Do you have a minimal example?

  Brian

On Wed, Mar 10, 2010 at 2:02 PM,  <travis@subspacefield.org> wrote:
> Hello all,
>
> Not sure where to ask this, apologies in advance if this isn't
> appropriate.  I'll only ask once, so ignoring me or a direct response
> will be sufficient.
>
> I'd like to call from one library (libfoo.a) to another (libbar.a) without
> directly linking the two.  In other words, I'd like to have the symbol
> resolved when I link the final executable.  I've tried "weak"
> attribute, and they work in some cases, like when the caller is not in
> a library, but on our platform, when you compile it into libraries, it
> gets left undefined... a call to the weak reference will segfault at
> run-time (I assume because it's not getting defined before the
>
> I'm just curious if there's an easy way to call from one .a to another
> to avoid drastically restructuring our code base.
>
> If this is unclear, please let me know.
> --
> A Weapon of Mass Construction
> My emails do not have attachments; it's a digital signature that your mail
> program doesn't understand. | http://www.subspacefield.org/~travis/
> If you are a spammer, please email john@subspacefield.org to get blacklisted.
>

Re: calling from one libfoo.a to another

[travis]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

On Wed, Mar 10, 2010 at 02:07:03PM -0800, Brian Budge wrote:
> I'm not sure I understand.  I believe that in the past I've done what
> you're talking about without issues.  Do you have a minimal example?

What follows is a minimal example of what I'm trying to do.
Problem is, on my test system,
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
it works.  On my target system, an embedded system that I'm targetting
with a cross-compiling gcc 3.x, and emulating, it fails.
My co-worker is reporting on his system that it is segfaulting, and that
may well be what's happening on the embedded/emulated system.  I know
that's a little vague, but the target system is very complex and
I'm still learning it.  Troubleshooting is painful...  at this point
I'm inferring errors from log files, as opposed to debugging with gdb
as I would normally.

14:03:41 travis@sevenheavens 2 0 bash$ cat main.c
int main () {
  weakcall();
}
14:07:53 travis@sevenheavens 2 0 bash$ cat call.c
extern void weak() __attribute__ ((weak));

void weakcall () { weak(); }
14:07:59 travis@sevenheavens 2 0 bash$ cat weak.c
#include <stdio.h>

void weak() { printf("hi\n"); }
14:08:01 travis@sevenheavens 2 0 bash$ cat Makefile 
#! /usr/bin/make -f

all: main.o weak.o
        gcc main.o foo.o

libweak.a: weak.o
        ar -rcs libweak.a weak.o

libcall.a: call.o
        ar -rcs libcall.a call.o

.PHONY: lib
lib: libweak.a libcall.a main.o
        gcc main.o -L. -lweak -lcall

.PHONY: clean
clean:
        rm *.a *.o a.out
-- 
A Weapon of Mass Construction
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john@subspacefield.org to get blacklisted.

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: calling from one libfoo.a to another

[Brian Budge]

 I admit, I'm unlikely to offer much good advice, as when I've done
this, neither have I cross compiled, nor have I run on an emulated
embedded system :)

My only suggestion is to try to eliminate potential causes.  If you
link in the .o files directly, does it work?  Have you tried a newer
gcc cross compiler?

  Brian

On Wed, Mar 10, 2010 at 2:16 PM,  <travis@subspacefield.org> wrote:
> On Wed, Mar 10, 2010 at 02:07:03PM -0800, Brian Budge wrote:
>> I'm not sure I understand.  I believe that in the past I've done what
>> you're talking about without issues.  Do you have a minimal example?
>
> What follows is a minimal example of what I'm trying to do.
> Problem is, on my test system,
> gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
> it works.  On my target system, an embedded system that I'm targetting
> with a cross-compiling gcc 3.x, and emulating, it fails.
> My co-worker is reporting on his system that it is segfaulting, and that
> may well be what's happening on the embedded/emulated system.  I know
> that's a little vague, but the target system is very complex and
> I'm still learning it.  Troubleshooting is painful...  at this point
> I'm inferring errors from log files, as opposed to debugging with gdb
> as I would normally.
>
> 14:03:41 travis@sevenheavens 2 0 bash$ cat main.c
> int main () {
>  weakcall();
> }
> 14:07:53 travis@sevenheavens 2 0 bash$ cat call.c
> extern void weak() __attribute__ ((weak));
>
> void weakcall () { weak(); }
> 14:07:59 travis@sevenheavens 2 0 bash$ cat weak.c
> #include <stdio.h>
>
> void weak() { printf("hi\n"); }
> 14:08:01 travis@sevenheavens 2 0 bash$ cat Makefile
> #! /usr/bin/make -f
>
> all: main.o weak.o
>        gcc main.o foo.o
>
> libweak.a: weak.o
>        ar -rcs libweak.a weak.o
>
> libcall.a: call.o
>        ar -rcs libcall.a call.o
>
> .PHONY: lib
> lib: libweak.a libcall.a main.o
>        gcc main.o -L. -lweak -lcall
>
> .PHONY: clean
> clean:
>        rm *.a *.o a.out
> --
> A Weapon of Mass Construction
> My emails do not have attachments; it's a digital signature that your mail
> program doesn't understand. | http://www.subspacefield.org/~travis/
> If you are a spammer, please email john@subspacefield.org to get blacklisted.
>

Re: calling from one libfoo.a to another

[travis]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

My coworker said he tried an example similar to mine on gcc 3.x and
the weak reference remains uninitialized, if it is defined in another
library.  On the other hand, if it is defined in the main compilation
unit (.o), the weak reference is resolved properly.

Our example couldn't be fixed by using ordinary externs and ordering
the libraries properly when linking because we have inadvertently
introduced a circular dependency; we are modifying libc to call
another library, which itself uses a bunch of libc functions.  Yeah,
yuck.

Our best guess at this point is that the weak attribute was not fully
polished in gcc 3.x, but works on 4.x.  It appears that we've found
a work-around involving a function pointer we initialize at run-time.
-- 
A Weapon of Mass Construction
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john@subspacefield.org to get blacklisted.

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]