It almost certainly is a link order issue. The GNU linker simply passes along the named object files, resolving against 
symbols already
discovered and noting unresolved references in the hope that they might be included in later object files.

Can you post the link line that is failing?

Jonathan Juniman wrote:
> My application relies on two statically-linked libraries, we'll call them a and b. Both libraries, plus the 
application, call VxWorks API functions, which reside in libvx2qnx.a. (This is the VxWorks->QNX porting library. It 
reimplements the VxWorks API using Posix and QNX API calls). I added all three libraries to the "extra libraries" list 
in the linker properties for the app.
> 
> The linker is able to resolve vx2qnx calls that originate from the app, but is unable to resolve vx2qnx calls that 
originate from libraries a and b.
> 
> I don't want to include libvx2qnx.a in the "extra libraries" list for libraries a and b, because I don't want a and b 
to have separate, though identical, implementations for each VxWorks API function. I want all VxWorks API calls to go to
 the same chunk of binary code.
> 
> I tried rearranging the order of the "extra libraries" list for the app, placing libvx2qnx.a first, before libraries a
 and b, but that didn't make any difference.
> 
> Any suggestions, anyone?
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post14977
> 

-- 
cburgess@qnx.com

Jonathan Juniman wrote:
> My application relies on two statically-linked libraries, we'll call them a and b. Both libraries, plus the 
application, call VxWorks API functions, which reside in libvx2qnx.a. (This is the VxWorks->QNX porting library. It 
reimplements the VxWorks API using Posix and QNX API calls). I added all three libraries to the "extra libraries" list 
in the linker properties for the app.
> 
> The linker is able to resolve vx2qnx calls that originate from the app, but is unable to resolve vx2qnx calls that 
originate from libraries a and b.
> 
> I don't want to include libvx2qnx.a in the "extra libraries" list for libraries a and b, because I don't want a and b 
to have separate, though identical, implementations for each VxWorks API function. I want all VxWorks API calls to go to
 the same chunk of binary code.
> 
> I tried rearranging the order of the "extra libraries" list for the app, placing libvx2qnx.a first, before libraries a
 and b, but that didn't make any difference.
> 
> Any suggestions, anyone?

libvx2qnx.a has to go last if both a and b reference it. The order they 
appear on the commmand line matter. The linker resolves symbols left to 
right.

Regards,

Ryan Mansfield

Could you try to do opposite: place libvx2qnx at the end of the list

Regards,

Alex

On 14/10/2008 1:51 PM, Jonathan Juniman wrote:
> My application relies on two statically-linked libraries, we'll call them a and b. Both libraries, plus the 
application, call VxWorks API functions, which reside in libvx2qnx.a. (This is the VxWorks->QNX porting library. It 
reimplements the VxWorks API using Posix and QNX API calls). I added all three libraries to the "extra libraries" list 
in the linker properties for the app.
>
> The linker is able to resolve vx2qnx calls that originate from the app, but is unable to resolve vx2qnx calls that 
originate from libraries a and b.
>
> I don't want to include libvx2qnx.a in the "extra libraries" list for libraries a and b, because I don't want a and b 
to have separate, though identical, implementations for each VxWorks API function. I want all VxWorks API calls to go to
 the same chunk of binary code.
>
> I tried rearranging the order of the "extra libraries" list for the app, placing libvx2qnx.a first, before libraries a
 and b, but that didn't make any difference.
>
> Any suggestions, anyone?
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post14977
>
>