Integrate 2 lib requiring a API with different arguments

Do you expect to call both routines from the same application? I believe this should be ok to have in separate libraries as long as only one of those is resolved in a given link. If you can provide more details of the use case I can try to get a better answer.

AartiG,

Sorry, I don't know the exact detail you need.

I only know:
  * It is a .out that runs in two modes, say modeE for 10sec and modeD for another 20sec.
  * In modeE, libE is invoked and it in turns calls GetArm926TcmBase(uint32* addr0, uint32* addr1, uint32 size0, uint32 size1) that I have to implement.
  * In modeD, libD is invoked and it in turns calls GetArm926TcmBase(uint32* addr0, uint32 size0) that I have to implement.

I have no source code of libE/libD and DLL(Dynamic Linked Lib) is not supported.
I 'thought' only one GetArm926TcmBase is generated in the .out,
both libE/libD call this GetArm926TcmBase, and one of libE/libD behaves wrong (even crash the system).

Thanks & regards,
Yulin.

Yulin,

It might be possible using the linker --symbol_map option to change the reference to GetArm926TcmBase() in one library to another function name with the proper call signature. I will describe this approach using a simple example.

Given:  libX.lib that contains a routine  foo_x() that calls bar(int a. int b):

extern int bar(int a, int b);

int foo_x()

{

     return bar(1, 2);

}

And a libY.lib that contains foo_y that calls another version of bar() with just 1 parameter:

extern int bar(int a);

int foo_y()

{

     return bar(1);

}

Define the different versions of bar into 2 separate files, but give one version a different name (eg bar2):

bar.c:

int bar (int a)

{

   return a;

}

bar2.c:

int bar2(int a, int b)

{

   return a + b;

}

Assuming libX.lib has only one reference to bar, use the archiver to extract the member which contains the reference to bar:

armar x libX.lib  foo_x.obj

Perform a partial link (--relocate) using the --symbol_map option to reroute references from bar to bar2:

armcl bar2.c foo_x.obj -z --relocate --symbol_map=bar=bar2 -o=new_foo_x.out

new_foo_x.out will now have the references to bar pointing at the definition of bar2.

Do final link to resolve the other reference to bar using the other definition:

armcl  bar.c <other files> -z -o -llibY.lib new_foo_x.out -llibX.lib -o final.out 

The references to bar in libY.lib uses the definition in bar.c while the references to bar in libX.lib were already resolved to bar2 in the partial link.

It is important that -libX.lib comes after new_foo_x.out so that the correct version of foo_x() is included in the link.

Your example will be more complicated since your libraries probably include other functions and might have multiple references so there may be more steps involved.

This example is just to outline an approach that may work. 

Regards,

John N

John N,

Thanks for taking care of this.

It seems that we use different tool chains.
I use TI CCS5/CGTv4.9.1 and it fails:
>> WARNING: invalid compiler option --relocate (ignored)
>> WARNING: invalid compiler option --symbol_map=GetArm926TcmBase=GetArm926TcmBase2 (ignored)

Regards,
Yulin.

These options should be supported with 4.9.1 TI tools. They are linker options so they must come after the -z (--run_linker) option.

Regards,

John N

John N,

I specify in the linker Command-line pattern.

Since NDA is involved, I wish I can "conversation" (a feature of this forum) with you in private.

Regards,

Yulin.

John N,

In the attachment 0804.relocate.zip, I tried your method and failed.
Build order is : libX --> libY --> new_foo_x --> main.
Please modify the attachment directly to demo this method correctly.

BR,
Yulin.

////////////////////////////////////////////////////////////////////////////
'Building target: ../../debug/new_foo_x.out'
'Invoking: TMS470 Linker'
"C:/ti/ccsv5/tools/compiler/tms470/bin/cl470" -mv5e -g -O2 --gcc --define="_DEBUG" --diag_warning=225 --diag_error=225 --display_error_number -me --abi=ti_arm9_abi --code_state=32 --printf_support=nofloat -z -m"../../debug/new_foo_x.map" --stack_size=1024 --heap_size=1024 --warn_sections -i"C:/ti/ccsv5/tools/compiler/tms470/lib" -i"C:/ti/ccsv5/tools/compiler/tms470/include" --relocatable --rom_model --relocate --symbol_map=bar=bar2 -o "../../debug/new_foo_x.out"  "./bar2.obj" "D:/prj/mtg_ccs5/shl/relocate/libX/Debug/foo_x.obj"
<Linking>
>> WARNING: invalid linker option --relocate (ignored)
warning #10247-D: creating output section ".text" without a SECTIONS specification
'Finished building target: ../../debug/new_foo_x.out'

////////////////////////////////////////////////////////////////////////////
'Building target: ../../debug/final.out'
'Invoking: TMS470 Linker'
"C:/ti/ccsv5/tools/compiler/tms470/bin/cl470" -mv5e -g -O2 --gcc --define="_DEBUG" --diag_warning=225 --diag_error=225 --display_error_number -me --abi=ti_arm9_abi --code_state=32 --printf_support=nofloat -z -m"../../debug/final.map" --stack_size=1024 --heap_size=1024 --warn_sections -i"C:/ti/ccsv5/tools/compiler/tms470/lib" -i"C:/ti/ccsv5/tools/compiler/tms470/include" --reread_libs --absolute_exe --rom_model -o "../../debug/final.out"  "./main.obj" "./bar.obj" "D:/prj/mtg_ccs5/shl/relocate/libY/Debug/libY.lib" "../link.cmd"  ../../Debug/new_foo_x.out  -l../../libX/Debug/libX.lib
<Linking>
'Finished building target: ../../debug/final.out'

Yulin,

Sorry about --relocate, should be --relocatable, as you already used.  Unfortunately, the --symbol_map option does not work with coff object files (--abi=ti_arm9_abi).  If you compile for ELF (--abi=eabi) does the example work?

Regards,

John N

John N,

The 3rd party libraries are --abi=ti_arm9_abi and can't be linked into a ELF.

BR,

Yulin.