Linker 'Other Object" setting fails if it contains spaces

thank you for the report, I'll investigate

to my surprise, the problem is not in my build plug-in, but in CDT.

the solution was to add a custom option generator for this field and add quotes, preventing the default generator to mess the strings.

the bad news is that the default generator might also mess other options; if you encounter other problems please let me know, and I'll add custom generators where necessary.

the beta version is available from updates-test, please try it on windows.

I tried to get the files from updates-test, but it failed?

An error occurred while collecting items to be installed
session context was:(profile=epp.package.cpp, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Artifact not found: http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.core_2.5.2.201501151741.jar.
http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.core_2.5.2.201501151741.jar
Artifact not found: http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.debug.core_1.2.1.201501151741.jar.
http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.debug.core_1.2.1.201501151741.jar
Artifact not found: http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.managedbuild.cross_1.12.1.201501151741.jar.
http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.managedbuild.cross_1.12.1.201501151741.jar
Artifact not found: http://gnuarmeclipse.sourceforge.net/updates-test/features/ilg.gnuarmeclipse.managedbuild.cross_1.12.1.201501151741.jar.
http://gnuarmeclipse.sourceforge.net/updates-test/features/ilg.gnuarmeclipse.managedbuild.cross_1.12.1.201501151741.jar
Artifact not found: http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.packs.core_1.1.2.201501151741.jar.
http://gnuarmeclipse.sourceforge.net/updates-test/plugins/ilg.gnuarmeclipse.packs.core_1.1.2.201501151741.jar

hmmm... recently SF is more and more moody... the mirrors are not consistent...

when this happens Eclipse is very confused. you need to remove the update source from the list, restart Eclipse and add it again.

if you still have problems, you can update from the archive I just published at

https://sourceforge.net/projects/gnuarmeclipse/files/Current%20Releases/test/

Today I was able to get the updates-test site working. However, the issue is not fixed?

make all
'Building target: FRDM-K64F_Semihosting.elf'
'Invoking: Cross ARM C++ Linker'
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -Wall -Wextra -g3 -T ../Project_Settings/Linker_Files/ProcessorExpert.ld -nostartfiles -Xlinker --gc-sections -lc -L"c:\temp\my folder" -L"C:\Tools\IDE\eclipse../toolchain/arm-none-eabi/lib/m4/fp/v4-sp-d16" "C:\Temp\my folder\libtest lib.a" -Wl,-Map,"FRDM-K64F_Semihosting.map" --specs=nano.specs --specs=rdimon.specs -o "FRDM-K64F_Semihosting.elf" ./Static_Code/System/CPU_Init.o ./Static_Code/System/Peripherals_Init.o ./Static_Code/System/Vectors.o ./Sources/Events.o ./Sources/main.o ./Project_Settings/Startup_Code/startup.o ./Generated_Code/Cpu.o ./Generated_Code/PE_LDD.o ./Generated_Code/Pins1.o C:/Temp/my\ folder/libtest\ lib.a -lc
arm-none-eabi-g++: error: C:/Temp/my\: No such file or directory
arm-none-eabi-g++: error: folder/libtest\: No such file or directory
arm-none-eabi-g++: error: lib.a: No such file or directory
make: *** [FRDM-K64F_Semihosting.elf] Error 1

this is strange, since on my machine the path is quoted, both for libraries and objects:

arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Og -fmessage-length=0
-fsigned-char -ffunction-sections -fdata-sections -fno-move-loop-invariants
-Wall -Wextra -g3 -T mem.ld -T libs.ld -T sections.ld -nostartfiles
-Xlinker --gc-sections -l"a b" -L"../ldscripts" "spa ce.o" -Wl,-Map,"lspace.map"
--specs=nano.specs -o "lspace.elf" $(OBJS) $(USER_OBJS) $(LIBS)

as you can see -l"a b" and "spa ce.o" are quoted.

I would say the upgrade went wrong.

I just published a new version, 2.5.2-201501171723, maybe this time the upgrade is less problematic.

Strange. I updated again from the non-test site (http://gnuarmeclipse.sourceforge.net/updates), and there is no 2.5.2-201501171723?
I have:
GNU ARM C/C++ Cross Compiler 1.12.1.201412191510
GNU ARM C/C++ Documentation (Placeholder) 1.1.1.201412191510
GNU ARM C/C++ Freescale Project Templates 2.2.3.201412191510
GNU ARM C/C++ Generic Cortex-M Project Template 1.2.3.201412191510
GNU ARM C/C++ J-Link Debugging 3.1.1.201412191510
GNU ARM C/C++ OpenOCD Debugging 2.1.1.201412191510
GNU ARM C/C++ Packs (Experimental) 2.2.1.201412191510
GNU ARM C/C++ STM32Fx Project Templates 2.2.3.201412191510

the new version is a beta, available from updates-test.

I thought I had that tried too. updates-test shows
GNU ARM C/C++ Cross Compiler 1.12.1.201501171723
GNU ARM C/C++ Documentation (Placeholder) 1.1.1.201501171723
GNU ARM C/C++ Freescale Project Templates 2.2.3.201501171723
GNU ARM C/C++ Generic Cortex-M Project Template 1.2.3.201501171723
GNU ARM C/C++ J-Link Debugging 3.1.2.201501171723
GNU ARM C/C++ OpenOCD Debugging 3.1.1.201501171723
GNU ARM C/C++ Packs (Experimental) 2.2.2.201501171723
GNU ARM C/C++ QEMU Debugging (Experimental) 1.1.1.201501171723
GNU ARM C/C++ STM32Fx Project Templates 2.2.3.201501171723

I will try it again.

I don't know what is wrong on my side.
I have the following from updates-test:
GNU ARM C/C++ Cross Compiler 1.12.1.201501200952
GNU ARM C/C++ Documentation (Placeholder) 1.1.1.201501200952
GNU ARM C/C++ Freescale Project Templates 2.2.3.201501200952
GNU ARM C/C++ Generic Cortex-M Project Template 1.2.3.201501200952
GNU ARM C/C++ J-Link Debugging 3.1.2.201501200952
GNU ARM C/C++ OpenOCD Debugging 3.1.1.201501200952
GNU ARM C/C++ Packs (Experimental) 2.2.2.201501200952
GNU ARM C/C++ QEMU Debugging (Experimental) 1.1.1.201501200952
GNU ARM C/C++ STM32Fx Project Templates 2.2.3.201501200952

If have cleaned the project, I have removed all the make files. Still it does incorrectly use the command line:

make all
'Building target: FRDM-K64F_Semihosting.elf'
'Invoking: Cross ARM C++ Linker'
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -Wall -Wextra -g3 -T ../Project_Settings/Linker_Files/ProcessorExpert.ld -nostartfiles -Xlinker --gc-sections -lc -L"c:\temp\my folder" -L"C:\Tools\IDE\eclipse../toolchain/arm-none-eabi/lib/m4/fp/v4-sp-d16" "C:\Temp\my folder\libtest lib.a" -Wl,-Map,"FRDM-K64F_Semihosting.map" --specs=nano.specs --specs=rdimon.specs -o "FRDM-K64F_Semihosting.elf" ./Static_Code/System/CPU_Init.o ./Static_Code/System/Peripherals_Init.o ./Static_Code/System/Vectors.o ./Sources/Events.o ./Sources/main.o ./Project_Settings/Startup_Code/startup.o ./Generated_Code/Cpu.o ./Generated_Code/PE_LDD.o ./Generated_Code/Pins1.o C:/Temp/my\ folder/libtest\ lib.a -lc
arm-none-eabi-g++: error: C:/Temp/my\: No such file or directory
arm-none-eabi-g++: error: folder/libtest\: No such file or directory
arm-none-eabi-g++: error: lib.a: No such file or directory
make: *** [FRDM-K64F_Semihosting.elf] Error 1

What else can I check?

you are right, I finally reproduced your problem.

it looks like 'make' is not able to parse properly quoted strings, and the entire patch to be worthless.

I tried several make.exe, from different sources, and indeed they behave differently, the one available in msys behaves correctly.

I'll try first to redo the plug-in, maybe I find a combination that works with the current make; otherwise I'll repack the Build Tools and include a newer make.

the conclusion is that the problem is definitely in make.exe.

I'll revert my changes, since the default CDT behaviour (convert windows path into posix path) is ok, there is nothing to do to get the line properly parsed by a broken make.

unfortunately I could not yet find a good make. the best fit was the one from msys, but it also has a bad default, it tries to call /bin/sh, which normally is not available; adding sh.exe locally is possible, but in this case make should be called with 'make SHELL=sh' which will break existing projects.

the solution is to compile make from sources, and change the default from SHELL=/bin/sh to SHELL=sh, which will remain on my TODO list, but currently with low priority.

https://sourceforge.net/p/gnuarmeclipse/feature-requests/85/

the conclusion is that the problem is definitely in make.exe.

after some further tests, this might be a rushed conclusion.

make definitely has a problem, since the newer msys make accepts the default space processing (convert windows path into posix path, with escaped spaces).

but, as seen right in the make console, the quoted strings are properly parsed; for example I used something like this:

-I"../inc lude" -std=gnu11 -MMD -MP -MF"src/sour ce.d" -MT"src/sour ce.d" -c -o "src/sour ce.o" "../src/sour ce.c"

in this case the problem is somewhere else, if you look closely, your definition is passed twice to the linker, once with quotes, which is correct, and once without, at the end, using the syntax not accepted by make.

I don't know yet how complicated it it is to fix, but this seems a cdt problem which, with a little bit of luck, might be able to fix in the plug-in.

unfortunately for LIBS and USER_OBJS I could not find a solution.

for options that are generated on the compiler/linker command line, like -L, quoting the string helps, but LIBS and USER_OBJS are collected in separate variables and expanded by make when the command is executed, where I have no access to quote each individual definition.

the only reliable solution is to use a proper make, but I have no time now to handle Windows builds. :-(

c:/temp/my\ folder/libtestlib.a which fails on Windows.

to be correct, "which fails with the CodeSourcery make" (which most use), because otherwise it works properly with msys make.

I was thinking on it, and the problem is somehow philosophical (and created by the shit-heads who invented the DOS backslash paths).

the differences between the two make behaviours reflect what is required for the make to do. if the make is required to process posix paths only, msys make is ok. for makefile projects generated by Eclipse managed build projects, this is easier to ensure, since by default Eclipse uses posix path (I had to struggle a lot to generate non-posix quoted paths, trying to adapt to the CodeSourcery make).

if the make is expected to process windows paths in hand written windows specific makefiles, than the msys make fails, and I guess this was the reason CodeSourcery (and possibly others) preferred the patched make that deviates from the posix paths.

these being said, I did my best and packed the msys make/rm/echo in such a way that Eclipse can use it, and all my tests with spaces in paths suddenly passed.

I'll prepare a new version of the Build Tools, and let you know the details.

after this I'll probably need to check and possibly revert some old patches to return to posix paths.

I'll prepare a new version of the Build Tools

done: https://sourceforge.net/p/gnuarmeclipse/beta-versions/17/

time permitting, please check it with complex projects, since my tests were only simple builds.

the make used in the recently released build-tools setup is too old, and parallel build hags.

the is another MSYS2 project, with up-to-date programs, that work both with spaces and parallel build, I'll update the setup to use them.

version v2.2 of the build tools, including a recent make which supports parallel builds, is available for download.

during development I finally discovered why some make accept spaces and why other not.

the problem is not in make, but in the shell they use. if make has a sh.exe available, it uses the shell to invoke sub-processes, and in this case sh, being a posix program, properly parses posix paths like a/b\ c/d; if sh.exe is not available, make tries to use cdm.exe to launch sub-processes, and in this case posix paths are not parsed properly (spaces can be passed only inside quotes).

you can tell when make uses cmd vs sh from the build console, if all commands are surrounded by apostrophes, then cmd is used, otherwise sh is used.

version v2.3 (hopefully final!) of the build tools is available for download.

all programs are static, no more dlls to worry about.

now, that make behaviour is fully understood, I'll check the plug-in behaviour when dealing with spaces, maybe there are some more details to fix.

for example, if you notice both quotes and escaped spaces (like "some\ thing"), please let me know, since it might need correcting.

I have downloaded and installed v2.3, and now this works :-).
If I see anything with quoted/escaped combination, I will submit a new ticket. But so far all my projects run fine.

Many thanks!

great!

it might be interesting to try again the project with very long command lines, maybe by not using the cmd.exe the limit is higher.

I did a test with a very long link line (>15K), and the build passed.

It looks like this new version of Build Tools also solved the command line limitation.

Please confirm.