Build/Linker error, new setup help

Pikefish

Greetings all, I'm new to this C++ and complex building, though not new to programming with eclipse, and got fairly deep into programming for the RAMPS.
It's my intention to build a machine with replaceable drivers (at least while prototyping) and auto true levelling, so for now I've bought a RADDS and am looking to build the firmware. I've downloaded the master branches of CoreNG and RepRapFirmware 1.18 from the git, followed the BuildInstructions.md to the letter with the exception of installing Eclipse Neon 3.0 rather than 2.0. I'm using the supplied 'RADDS' configuration for C/C++ Build, and CoreNG builds happily, RepRapFirmware then hits the error below. I've corrected various paths and installed all the CDT plugins that varius sources have specified, and Arduino C++ Tools (though BI.md said it wasn't necessary, and I can't recall whether it helped something to work). I'm trying to build it unmodified, with everything default, before I start playing. I'm on W7hp, and have an eclipse juno java dev installed elsewhere.

From what I've read, "_sbrk" is a common memory management thing, I guess it should be getting included along with CoreNG\RADDS\cores\arduino\syscalls.o (or syscalls.d?), but this error suggests otherwise. In other instances of this error I've read about, syscalls.c was not included and including it fixed things. I've not been able to get any change by more forcefully making it include syscalls with a -u or specifying the file in the file includes, but I'm hoping the problem is poorly reported and obvious and simple that I just need to tick a radio box somewhere and it'll work.

extern caddr_t _sbrk ( int incr )
{ etc.

```from C:\Eclipse\Firmware\CoreNG\cores\arduino\syscalls.c is the thing it needs, right? Anyone know what I'm missing? Cheers!

18:22:12 **** Incremental Build of configuration RADDS for project RepRapFirmware ****
make all
'Building target: RepRapFirmware.elf'
'Invoking: Cross G++ Linker'
arm-none-eabi-gcc -L"C:\Eclipse\Firmware\CoreNG\RADDS" -Os -Wl,--gc-sections -Wl,--fatal-warnings -mcpu=cortex-m3 -TC:\Eclipse\Firmware\CoreNG\variants\RADDS\linker_scripts\gcc\flash.ld -Wl,-Map,C:\Eclipse\Firmware\RepRapFirmware\RADDS/RepRapFirmware.map -o "RepRapFirmware.elf" -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group ./src/Storage/FileStore.o ./src/Storage/MassStorage.o ./src/RADDS/Network.o ./src/Movement/DDA.o ./src/Movement/DeltaParameters.o ./src/Movement/DeltaProbe.o ./src/Movement/DriveMovement.o ./src/Movement/Grid.o ./src/Movement/Move.o ./src/Libraries/sha1/sha1.o ./src/Libraries/Math/Isqrt.o ./src/Libraries/General/StringRef.o ./src/Libraries/Fatfs/ccsbcs.o ./src/Libraries/Fatfs/diskio.o ./src/Libraries/Fatfs/fattime_rtc.o ./src/Libraries/Fatfs/ff.o ./src/Heating/FOPDT.o ./src/Heating/Heat.o ./src/Heating/Pid.o ./src/Heating/TemperatureError.o ./src/Heating/TemperatureSensor.o ./src/Heating/Thermistor.o ./src/GCodes/GCodeBuffer.o ./src/GCodes/GCodeInput.o ./src/GCodes/GCodeMachineState.o ./src/GCodes/GCodeQueue.o ./src/GCodes/GCodes.o ./src/GCodes/GCodes2.o ./src/Fan.o ./src/OutputMemory.o ./src/Platform.o ./src/PrintMonitor.o ./src/RepRap.o ./src/RepRapFirmware.o ./src/Roland.o ./src/Tool.o -lCoreNG -Wl,--end-group -lm -gcc
c:/arduino-1.5.8/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7-m\libg.a(lib_a-sbrkr.o): In function _sbrk_r': sbrkr.c:(.text._sbrk_r+0xc): warning: undefined reference to _sbrk'
collect2.exe: error: ld returned 1 exit status
make: *** [RepRapFirmware.elf] Error 1

18:22:13 Build Finished (took 979ms)

deckingman

If I understand correctly, you haven't bought a Duet board but instead a Radds board that you need help with?

dc42

The linker map file from my RADDS build indicates that _sbrk is indeed coming from CoreNG\cores\arduino\syscalls.c. Perhaps your libCoreNG.a library file is incomplete? Mine is 343 KB (351,904 bytes) in size.

Pikefish

deckingman: technically true, I'm prototyping with the less-expensive-to-blow-up-parts-of RADDS, but I indend to purchase a few duet ethernet after proof of concept. The setup of this build process leads me to believe the transition wouldn't be difficult, but alas I've only had a couple of days getting to know it. If this firmware sub-forum isn't the place to service the firmware developed with it and it's related uses, I can try others. The issue I'm having isn't due to the RADDS board itself, though maybe part of the configuration to support it, or some small thing missing from the build instructions. I expect I'd be having the same problem if I'd bought a duet and tried to build from source.

dc42: My libCoreNG.a also comes out at 351,904 bytes, and contains multiple instances of the string "_sbrk".
When I build libCoreNG.a, the log does confirm that ./cores/arduino/syscalls.o is in the group.
When I enable RepRapFirmware's Cross GCC Compiler debugging prof information -p, the error changes to:```
c:/arduino-1.5.8/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -lc_p
collect2.exe: error: ld returned 1 exit status

In the RADDS directory created in RepRapFirmware when building, as far as I understand the makefile uses one library -L"C:\Eclipse\Firmware\CoreNG\RADDS", which is the directory where libCoreNG.a is, then objects.mk appends it's LIBS := -lCoreNG. From what I read, ld.exe adds lib and .a so it's a second time accurately looking for libCoreNG.a, by coming from the Cross G++ Linker > Libraries with ${CoreName}, looking in the directory that libCoreNG.a is. Finally LINK_FLAGS_2 adds maths with -lm.
When I broke it by removing the directory of libCoreNG.a from Cross G++ Linker > Libraries, it did indeed complain about being unable to find it, so that part is getting called before my error wall.
Can it still be an order of libraries problem?

Pikefish

Good news! I've fixed it, the solution was the first thing anyone should try, turning it off and on again.
I went to check the veracity of my first assumption that it'd be the same building for duet, so activated those configurations and started fixing up the paths there. I tried a tentative build and found a bunch of new red conflicts, decided to go back to the problem I wanted fixed, so I deleted the output folders it'd generated and set it up for RADDS again, it worked first go. Do the paths need to be set for GCC Build configurations other than RADDS alone? Either that, or there was a bug in eclipse that wasnt recognising something until it had been re-re-written.
Glad to see it really was as easy as it should be. Cheers!

dc42

If might be worth comparing your .cproject file with mine from github and checking that they are the same except where the file paths should be different.

Pikefish

Sure, here it is from RepRapFirmware master vs mine, available for the next day: https://www.diffchecker.com/NKsFgpWJ
I'm seeing stuff added by my attempts to get more useful debug information, there are multiple mentions of the macro called MAKE that I erroneously created first like the rusty newb I was instead of adding the dir of make.exe to the PATH, must have propagated it to all configurations. I had corrected it in the active configurations called RADDS. Is there some use of stuff in other configurations outisde of the active configuration, because I wasn't expecting that to matter, but I was also fixing up some of it when the error disappeared.

Pikefish

I've been poking it again, went through all the configurations and gave them paths in most of then hopefully all of the right places, and used the gcc from Arduino 1.5.8 again. Naturally this broke everything, eventually I got back to the _sbrk error, and the same fix of switching active to sam3x8e and duetethernet, building that unsucessfully, then switching back to RADDS and RADDS, it worked again. It's produced a .bin that's 240,692 bytes, which is in the right ball park, so I think it's ok.
Here's my latest .cproject comparison after I cleared out some needless differences, and reinstated managedBuildOn="true" into the RepRapFirmware builder buildPath section. I don't know how it became absent but it doesn't seem to have made a difference. https://www.diffchecker.com/tvIMEOMs

dc42

Check the linker command line displayed just before the error message. Mine is this:

'Building target: RepRapFirmware.elf'
'Invoking: Cross G++ Linker'
arm-none-eabi-gcc -L"C:\Eclipse\Firmware\CoreNG\RADDS" -Os -Wl,--gc-sections -Wl,--fatal-warnings -mcpu=cortex-m3 -TC:\Eclipse\Firmware\CoreNG\variants\RADDS\linker_scripts\gcc\flash.ld -Wl,-Map,C:\Eclipse\Firmware\RepRapFirmware\RADDS/RepRapFirmware.map -o "RepRapFirmware.elf"  -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group C:\Eclipse\Firmware\CoreNG\RADDS\cores\arduino\syscalls.o  ./src/Tools/Filament.o ./src/Tools/Tool.o  ./src/Storage/FileStore.o ./src/Storage/MassStorage.o  ./src/RADDS/Network.o  ./src/Movement/Kinematics/CartesianKinematics.o ./src/Movement/Kinematics/CoreBaseKinematics.o ./src/Movement/Kinematics/CoreXYKinematics.o ./src/Movement/Kinematics/CoreXYUKinematics.o ./src/Movement/Kinematics/CoreXZKinematics.o ./src/Movement/Kinematics/Kinematics.o ./src/Movement/Kinematics/LinearDeltaKinematics.o ./src/Movement/Kinematics/ScaraKinematics.o  ./src/Movement/BedProbing/Grid.o ./src/Movement/BedProbing/RandomProbePointSet.o  ./src/Movement/DDA.o ./src/Movement/DriveMovement.o ./src/Movement/Move.o  ./src/Libraries/sha1/sha1.o  ./src/Libraries/Math/Isqrt.o  ./src/Libraries/General/StringRef.o  ./src/Libraries/Fatfs/ccsbcs.o ./src/Libraries/Fatfs/diskio.o ./src/Libraries/Fatfs/fattime_rtc.o ./src/Libraries/Fatfs/ff.o  ./src/Heating/Sensors/CpuTemperatureSensor.o ./src/Heating/Sensors/CurrentLoopTemperatureSensor.o ./src/Heating/Sensors/RtdSensor31865.o ./src/Heating/Sensors/SpiTemperatureSensor.o ./src/Heating/Sensors/TemperatureSensor.o ./src/Heating/Sensors/Thermistor.o ./src/Heating/Sensors/ThermocoupleSensor31855.o ./src/Heating/Sensors/ThermocoupleSensor31856.o ./src/Heating/Sensors/TmcDriverTemperatureSensor.o  ./src/Heating/FOPDT.o ./src/Heating/Heat.o ./src/Heating/Pid.o ./src/Heating/TemperatureError.o  ./src/GCodes/GCodeBuffer.o ./src/GCodes/GCodeInput.o ./src/GCodes/GCodeMachineState.o ./src/GCodes/GCodeQueue.o ./src/GCodes/GCodes.o ./src/GCodes/GCodes2.o ./src/GCodes/RestorePoint.o  ./src/Fan.o ./src/OutputMemory.o ./src/Platform.o ./src/PortControl.o ./src/PrintMonitor.o ./src/RepRap.o ./src/RepRapFirmware.o ./src/Roland.o ./src/Scanner.o   -lCoreNG -Wl,--end-group -lm -gcc
'Finished building target: RepRapFirmware.elf'

I suspect you will find that the syscalls.o entry missing after –start-group. The setting that causes this to be added is this Command Line Pattern in the Crops Gcc Linker settings:

${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT}  ${LINK_FLAGS_1} ${workspace_loc:/${CoreName}/RADDS/cores/arduino/syscalls.o} ${INPUTS} ${LINK_FLAGS_2}

If CoreName is not set correctly, this would resolve to the wrong path. To check that variable, look under C/C++ Build -> Build variables.

The other thing that might go wrong is if your workspace path has a space in it. I just tried changing the command line pattern to this:

[[language]]
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT}  ${LINK_FLAGS_1} "${workspace_loc:/${CoreName}/RADDS/cores/arduino/syscalls.o}" ${INPUTS} ${LINK_FLAGS_2}

(i.e. quotes around the file path/name) which works and should cope with spaces in the workspace path.

HTH David

prot0typ1cal

The CoreName is set to CoreNG in the C/C++ Build>Build Variables.
Interestingly, when I added the quotes around the syscall.o path string, get –start-group ""
Hmm... what if,

Replaced
${workspace_loc:/${CoreName}/RADDS/cores/arduino/syscalls.o}

with
C:\Eclipse\Firmware\CoreNG\RADDS\cores\arduino/syscalls.o

Success!!! Generated bin file.
Funny, building Lars CoreXYU fork for Duet085 the string is:
${workspace_loc:/${CoreName}/SAM3X8E/cores/arduino/syscalls.o}
and builds fine.