While cross compiling a linux elf on a windows PC I found an odd bug/issue/problem that I'm not sure whether is an FPC problem or a linker problem

Here's what I did:
Passed this -k option:
-kc:\test\test\test\test\test\test\ld-linux.so.2

Got error: Error: Can't call the linker, switching to external linking

If I shorten the path to something like:
-kc:\abc\abc\test\test\test\test\ld-linux.so.2

I get the correct error that should display, since that file does not exist: No such file: No such file or directory

So the problem I have is it is reporting "Can't call the linker" with that long path above - when in fact it should be reporting "no such file".

Yes, I did successfully compile my program by throwing the ld-linux.so.2 file into c:\tmp\ . That's a nice short path that always works ;-)

But that's not a elegant solution.. any idea why -k would be having trouble chomping long paths? From what I can tell it doesn't appear to be a 255 string limit, which always does come to mind.

Just posting some more information: here is the verbose output when using the -va option:

Searching file c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ld.exe... found Using util c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ld.exe hello.pas(16,1) Error: Can't call the linker, switching to external linking Error: c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ppc386.exe returned an erro r exitcode (normal if you did not specify a source file to be compiled)

It does find the linker.. but the long -k path (about 48-100 characters long) some how causes issues and reports back that it can't call the linker! Hmm..

When I pass a -k path which is about 5-44 characters long (nice and short) it reports a correctly and works fine:

Searching file c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ld.exe... found Using util c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ld.exe c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ld.exe: c:\abc\abc\test\test\test\ test\ld-linux.so.2: No such file: No such file or directory hello.pas(16,1) Error: Error while linking
Error: c:\pascal\FPC-2.0.2-CrossLinux\bin\i386-win32\ppc386.exe returned an erro r exitcode (normal if you did not specify a source file to be compiled)

Because the path is not found, which is 100% right. It's just a made up "dummy" directory to see if errors are working properly.

It seems to be in the 48-100 character path length range which causes issues, but I can't get a definite number like 48 or 47, since I've noticed fluctuations, or maybe my eyes are sore from counting characters on the screen today too much.

BTW - if anyone is interested in cross compiling I recommend making a copy of fpc.exe and renaming it to fpc-lin.exe, moving it to a new directory and just switching your compiler path to c:\fpc-cross\bin\fpc-lin.exe when you want to cross compile. This saves you having to re-copy the as, ld, ar files each time you want to revert back to normal compiling. Because AFAIK, using a cross compiler AS/AR/LD utility requires you copy the old files back, each time you want to switch from normal compiles to cross-compiles. Keep two directories for fpc:
1. A regular fpc compiler directory containing fpc.exe
2. A cross compiler directory containing fpc-lin.exe.

Remember to add the directory fpc-lin.exe is in to your system environment (edit your ControlPanel/System/AdvancedTab/ PATH)

Renaming one of the fpc files to fpc-lin ensures that when you call fpc-lin it pulls in the right directory for cross compiling. And if you use lazarus, each time you cross compile you just switch your compiler path to that new cross compiling directory.

If this is not as an elegant of a solution that someone else has found - let me know. If it is an elegant solution, then it should probably be noted that the IDE's like fp-ide and lazarus IDE should have an option for a "cross compiler" directory in addition to the regular FPC directory.

For the reference, I'll be reporting some notes about cross compiling here too: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Compiling-Linux-Elf-on-Windows

Try to add a LD param that increases LD's verbosity. Then see if the problem is LD's parsing. It could be that there are still shortstrings here and there in the compiler, but <255 chars limits are not likely.

Read the buildfaq. There are easier ways. E.g. you can set a prefix for the binutils using -XP, even automatically, in your fpc.cfg

E.g.
#ifdef FPC_CROSSCOMPILING
-XP$FPCTARGET
#endif

in your fpc.cfg (untested)

Try to add a LD param that increases LD's verbosity. Then see if the problem is LD's parsing. It could be that there are still shortstrings here and there in the compiler, but <255 chars limits are not likely.

The LD man page says to pass --verbose .. will do some testing and report back what I find.

Thanx I need to study my compiler options more.

Passing --verbose option actually inflicts my problem! it doesn't report back anything verbose because the --verbose is a few extra characters over the limit of whatever the limit is I'm hitting.. hmmm...

Bizzare .. so in other words it's a general character length problem not specifically within the -k option itself. But it is hard to reproduce because when I append something like -Fuc:\long\path\long\long\long\ it doesn't affect the problem - but yet adding text elsewhere in the command does affect the problem, such as when I add text into the -o option. Maybe I'll just copy and paste the exact command I'm sending and someone else can try reproduce the problem if they have time.

I've also experienced random issues inside Lazarus (above testing was done at the command line). In lazarus sometimes I get a chopped off message stating "cannot find ar.e" when it instead should say "cannot find ar.exe". This is not the exact message I received, just a pseudo example. I've had chopping off problems before.. but hard to find the cause and reproduce.

The compiler mainly uses shortstrings for passing parameters to external tools.

Jonas

I looked into FPC sources, and since 44-50 character area was something I was hitting, I think I will play around in /compiler/compsrc.pp

Here is some suspicious evidence I found:

  s:=target_res.rescmd;
  ...
  try
   if ExecuteProcess(resbin,s)  0 then
   begin
     Message(exec_e_error_while_linking);
     aktglobalswitches:=aktglobalswitches+[cs_link_extern];
   end;

And TResInfo is defined as follows:

     tresinfo = record
        id      : tres;
        resbin  : string[8];
        rescmd  : string[50];
     end;