Including a file using the linker on the command line

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Including a file using the linker on the command line

Jump to solution
2,241 Views
benfleming
Contributor II

I am trying to use the Coldfire linker on the command line (CodeWarrior 7.1.2). I have an LCF file which includes two binary images, and it links successfully in the IDE. The images have the .gz extension. In the IDE I have file mappings added for .gz, so the linker happily includes them in the final elf.

The situation for the CLI linker is different, however. It instead provides me with this error:

### mwldmcf Linker Error:
# Linker command file error at line 84
# File not found: dsp.coff.gz
### mwldmcf Linker Error:
# Link failed.

Errors caused tool to abort.
make: *** [software.elf] Error 1

 

In my LCF I have this section:

.text :
 {
 *(.text)
 . = ALIGN (0x8);
 *(.rodata)
 . = ALIGN (0x8);
 __start_of_zipped_dsp = .;
 INCLUDE dsp.coff.gz
 __end_of_zipped_dsp = .;
 __start_of_zipped_fpga = .;
 INCLUDE fpga.gz
 __end_of_zipped_fpga = .; 
 ___ROM_AT = .;
 ___DATA_ROM = .;
 } > code

 

I have tried including the path to the gz files using -Lpath/to/gz/files, which has no effect. Specifying the files as libraries doesn't work, as the linker doesn't understand that it needs to treat them as resources.

As far as I can tell, I need to either rename them to a pre-defined extension, or inform the linker about the .gz extension. This is easy to do in the IDE, but I haven't found mention of how to do it on the CLI. 

Does anyone know if there are any pre-defined resource extensions, or better yet, a way to inform the linker that an extension is a resource?

 

Thanks

-Ben

Labels (1)
0 Kudos
1 Solution
1,529 Views
stanish
NXP Employee
NXP Employee

Hi Ben,

If you are building your project from CLI you should pass the binary files as an input files for linker (same as e.g. object files) e.g.:

mwldmcf.exe [linker_flags] file1.o file2.o binary_file1.bin binary_file2.bin ….  -o Out.elf

so if it does not work I'd suggest to try to enter absolute path to figure out if it's a path issue or not.

mwldmcf.exe [linker_flags] file1.o file2.o c:\My_Project\bin\binary_file1.bin c:\My_Project\bin\binary_file2.bin ….  -o Out.elf

Hope it helps.

Stan

View solution in original post

0 Kudos
10 Replies
1,529 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Ben Fleming

Sorry for the late reply, How is the status of your issue?

Unfortunately with command line you cannot specify that it needs to treat them as resources, this is something that the compiler need to know to "read the file".

But alternatively you could renamed your .gz file as .bin. Files in *.bin is a pre-defined extension that are treated as resources in CodeWarrior 7.

Hope this help

Best Regards

Jorge Alcala

0 Kudos
1,529 Views
benfleming
Contributor II

I have tried this, renaming them to bin files, but the linker still complains that it cannot find them. Oddly, I have also tried renaming them to .o, expecting to get a 'cannot parse' type error instead, but I still get a file-not-found error. I have added the path to the libraries using the -L option, but it seems to have no effect either.

0 Kudos
1,529 Views
stanish
NXP Employee
NXP Employee

Hi Ben,

Could you possibly try to pass the binary file(s) to linker using an absolute path?

Does it work?

Stan

0 Kudos
1,529 Views
benfleming
Contributor II

Hi Stan,

I'm not sure it's possible to enter a path after INCLUDE in the linker control file. I've tried both absolute and relative paths there, with and without surrounding double-quotes, and from the error messages it appears the linker is not expecting a path. Then again, there could be some other way to enter a path that I don't know about.

Ben

0 Kudos
1,530 Views
stanish
NXP Employee
NXP Employee

Hi Ben,

If you are building your project from CLI you should pass the binary files as an input files for linker (same as e.g. object files) e.g.:

mwldmcf.exe [linker_flags] file1.o file2.o binary_file1.bin binary_file2.bin ….  -o Out.elf

so if it does not work I'd suggest to try to enter absolute path to figure out if it's a path issue or not.

mwldmcf.exe [linker_flags] file1.o file2.o c:\My_Project\bin\binary_file1.bin c:\My_Project\bin\binary_file2.bin ….  -o Out.elf

Hope it helps.

Stan

0 Kudos
1,529 Views
benfleming
Contributor II

That was it - the input files were not specified on the command line. Somehow from the documentation I incorrectly understood they needed to be included like library paths.

Now I'm running into an issue where the linker complains it cannot find symbols defined in my .lcf:

### mwldmcf Linker:
# 40: Referenced from "fbcs_init" in 
# Error: ^
# Undefined : "__FLASH0_ADDRESS"

and in my .lcf:

SECTIONS
{

 ___FLASH0_ADDRESS = 0x00000000;
 ___FLASH0_SIZE = 0x01000000;
}
0 Kudos
1,529 Views
stanish
NXP Employee
NXP Employee

Hi Ben,

Thanks for the update.

Could you please check you correctly imported these linker symbols into the appropriate .c/.h files:

extern long ___FLASH0_ADDRESS;

extern long ___FLASH0_SIZE;

 

Stan

0 Kudos
1,529 Views
benfleming
Contributor II

The .lcf and code base were correctly compiling from the IDE. The linker symbols were imported as such:

extern uint8 __FLASH0_ADDRESS[];
extern uint8 __FLASH0_SIZE[];

(two underscores) - this works fine when linking from the IDE; it appears that the compiler prepends a single underscore to every symbol. Again, this doesn't work when linking from the CLI.

I tried them with 3 underscores:

extern uint8 ___FLASH0_ADDRESS[];
extern uint8 ___FLASH0_SIZE[];

and also imported as long, with three underscores:

extern long ___FLASH0_ADDRESS[];
extern long ___FLASH0_SIZE[];

and in both cases I still got 

# 40: Referenced from "fbcs_init" in 
# Error: ^
# Undefined : "___FLASH0_ADDRESS"
0 Kudos
1,529 Views
benfleming
Contributor II

Never mind. I was getting these errors because at some point I fat-fingered the linker command in my makefile in such a way that it caused my LCF to be excluded from the command line. 

0 Kudos
1,529 Views
stanish
NXP Employee
NXP Employee

Ben,

thanks for sharing the resolution with us.

Regards,

Stan

0 Kudos