• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 1929 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Case sensitivity in linker files

Eugene K
Expert 1685 points


Are linker files case sensitive on Windows PCs? The following constructs produce different results with ARM 4.6.4:

        .os_ram
        {
           Os_*.lib (.bss, .data)
        } palign(4)

links as expected

        .os_ram
        {
           os_*.lib (.bss, .data)
         } palign(4)

does not find any of os_*.lib files. OS files are named as Os*.

Is this case sensitivity on Windows PC expected behavior?

Eugene

  • 0
    TI__Guru**** 251290 points

    Eugene,

    I think I know what is going on.  I'll explain my guess here, and ask some experts to comment further.

    If a full file name without any wildcards is specified, that filename is the string the linker supplies to Windows to access the file.  Windows handles such a filename without regard to case.  If a wildcard is part of the filename, then the linker, not Windows, searches through the list of files given on the command line (or perhaps in a directory?) to find files which match the pattern.  This pattern match does consider case.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1685 points

    George,

    Thank you for information on linker wildcard processing. It explains some unrelated behavior that I have seen. However, for this particular case with using lower case wildcard spec for files with capitalized letters, linker is not allocating input section to required output ones.

    os_*.lib (.text, .const)

    creates

    .text      0    00015018    00011380    
    ...

                      00020b64    00000120     Os_Kernel.lib :  Setevent.obj (.text:OS_SetEvent)

    with following warning

    "linker.cmd", line 215: warning #10068-D: no matching section

    pointing to the Os_*.lib (.text, .const) line.

    but

    Os_*.lib (.text, .const)

    creates

    .os_code   0    000080a0    000044c8    
    ...

                      000099c8    00000118       Os_Kernel.lib : Setevent.obj (.text:OS_SetEvent)

    There is some case sensitivity here. Or may be it is something else?

    Eugene

  • 0
    TI__Expert 6550 points

    The case sensitivity is between the input of file names to the linker, or when invoking the linker to the shell, and the linker command file. So:

    - if you have a library named Os_try.lib and the command to link is: cl470 ... -z -l Os_try.lib the linker command file must contain Os_*.lib.

    - if the library is named os_try.lib and used as cl470 ... -z -l os_try.lib and the lcf has Os_*.lib you will get the "no matching section" warning. The linker will still be able to open the library and find symbols and place sections since this is basically an fopen call to the Windows OS.

  • 0 in reply to ThomasS
    Expert 1685 points

    This is exactly my use case. But, is this linker behavior correct on non-case sensitive file systems?

  • 0 in reply to Eugene K
    TI__Expert 6550 points

    There are 2 interfaces involved here. One is case-sensitive and one is based on the OS.

    1. The use of file names in the linker command file is case-sensitive. Any file name in a linker command file must match the case used in file name arguments passed to the shell.

    2. The use of file names as input to the linker, meaning object file names or library names, is based on the case-sensitivity of the OS. The linker will open object files or libraries if the case is different if the OS allows it.

    So there is an inconsistency here. You could pass a file name to the linker that the linker will open, but if the case does not match the use in the linker command file you will not get a match you intended for your Section specifiers or directives.