compile error arduino mega 2560

getting this error comming up when I try to compile marlin 3d printer source. Compiling... ? Preprocessing... ? Converting binary files ? Compiling sketch... ? Error at line 0 in file : ? macro names must be identifiers

Compiling Failed

where is this command line am using version 11.7 in windows

Attachments: 

Comments

Compiling...

Compiling... ? Preprocessing... ? Converting binary files ? Compiling sketch... ? Error at line 0 in file command-line ? macro names must be identifiers

Compiling Failed

Have done a complete cleanout

Have done a complete cleanout of ucide and arduino then a clean install with only the one board. now get Compiling... • Preprocessing... • Converting binary files • Compiling sketch... • Compiling core... ‣ arduino • Compiling libraries... • Linking sketch... C:\Users\DRIEDE~1\AppData\Local\Temp\ccIeaEZ8.ltrans0.ltrans.o: In function main': C:\Users\Driedeker\Local Settings\Application Data\UECIDE\cores\arduino\arduino/main.cpp:43: undefined reference tosetup' C:\Users\Driedeker\Local Settings\Application Data\UECIDE\cores\arduino\arduino/main.cpp:46: undefined reference to `loop' collect2.exe: error: ld returned 1 exit status Compiling Failed

The error at line 0 problem

The error at line 0 problem is usually because of an old board with the new core. The clean install would have sorted that out for you.

As for the undefined references to setup and loop, do you have a link to the code you're trying to compile?

If it's the firmware that I

If it's the firmware that I think it is, it's in a newer layout that UECIDE doesn't currently support. The development branch does, so I'll look at back-porting that functionality to the main trunk.

Ok, I've released 0.11.8

Ok, I've released 0.11.8 which should fix the problem. It's also highlighted a problem with the development branch's compilation as well, which is good. This Marlin firmware makes for a good test case...

Once I got your config into

Once I got your config into the right place (...! me == idiot) compilation of the CrealityDwin_2.0 branch of that github repo proceeded fine in 0.11.8.

can you put the hex file up

can you put the hex file up here as i still can not get it to compile here. error

Unable to start process Cannot run program "C:\Users\Driedeker\Local Settings\Application Data\UECIDE\compilers\avr-gcc/bin/avr-gcc" (in directory "C:\Marlin-CrealityDwin_2.0\Marlin\build"): CreateProcess error=206, The filename or extension is too long Compiling Failed

That sounds like some

That sounds like some limitation of Windows. I'll boot up my VM and have a play. Here's the HEX for you though anyway.

Attachments: 

Yeah, it's the linking phase.

Yeah, it's the linking phase. There are just far too many files on the link command line for Windows to be able to cope with. Sensible operating systems are fine with it, but Windows isn't.

I tried deleting all the HAL folders for platforms that aren't needed, but it was still just far too long.

I think I'm going to have to archive all the utility and src files after compilation and link against those archives instead.

The problem lies here: https:

The problem lies here: https://support.microsoft.com/en-gb/help/830473/command-prompt-cmd-exe-command-line-string-limitation - a limit of 8192 characters on a Windows command line. A little restrictive and short sighted by Microshaft...

I have tried archiving src but it's just not liking it. Best I have got is it can't find yield(). Some problem with it being a weak symbol.

So I have been looking at shortening the command line in other ways - and I have managed to get it down to 18kB - more than double the length it's allowed to be. Just the list of object files with relative path names (the shortest I can make them) is 18317 bytes. Removing the HAL folders that aren't needed takes it down to 14446 bytes. Still way too big.

There's just far too many files in this project, and having multiple files named the same in different folders hasn't helped. Neither does having loop() and setup() not in the main INO file. But it's obvious that the developers aren't Arduino IDE users (it's set up primarily for Platform.IO usage).

So I'm not sure quite how I can tackle this problem. I guess I could shrink all the filenames to s0002.o or something, though that's a nasty hack and I'd rather not do that. Archiving really is the way to go, but it just doesn't like it at all.

Typical. The moment I post

Typical. The moment I post that suddenly the archive method starts working. Well, in the development branch, anyway. Not much hope of getting it to work in trunk though, the compilation routines are too broken in there.

I'm wondering if I should publish an alpha demo version of the development branch. It's far from complete, but is at a stage where it's usable. There's lots and lots of things still missing that I need to reimplement from scratch, but it's gradually getting there.

I'll give it a test in Windows first and then maybe think about pushing out a compiled version that you could maybe play with.

And no... it's not working in

And no... it's not working in windows. Can't find millions of symbols. I hate Windows. I don't know how anyone can actually use it for anything more than writing letters.


Of course - Windows' janky path separator breaking my filename munging routine. Why can't they just do the same as everyone else?! They always have to do their own thing, and do it badly! Bah! HATE WINDOWS!

will try your update later

will try your update later but this is my findings so far Ok latest is have installed arduino ide and Uecide 11.8 on my new win 10 games machine both set up with same arduino/genuino mega or mega 2560 boards arduino compiles it ok uecide has the same long file name error as before. I also did the same with a mac laptop and both arduino and Uecide compiled fine. will try your update and get back to you.

That's a shame. It was worth

That's a shame. It was worth a try. If you have the time we can try diagnosing the problem. If you had the zip version there should be a uecide-cli.exe which you can run from a command window. If you include the --exceptions command line option it should give you some text to tell you why it's failing.

used --log=file.txt

used --log=file.txt result is

0 packages can be upgraded.
java.lang.NullPointerException
    at org.uecide.actions.Action.run(Action.java:66)
    at org.uecide.Context.action(Context.java:1036)
    at org.uecide.UECIDE.createContext(UECIDE.java:1327)
    at org.uecide.UECIDE.createContext(UECIDE.java:1300)
    at org.uecide.UECIDE.<init>(UECIDE.java:522)
    at org.uecide.UECIDE.main(UECIDE.java:133)
Exception in thread "usb4java Device Scanner" java.lang.IllegalStateException: Device already attached
    at org.usb4java.javax.AbstractDevice.setParentUsbPort(AbstractDevice.java:270)
    at org.usb4java.javax.Port.connectUsbDevice(Port.java:79)
    at org.usb4java.javax.Ports.connectUsbDevice(Ports.java:123)
    at org.usb4java.javax.Hub.connectUsbDevice(Hub.java:90)
    at org.usb4java.javax.Hub.connectUsbDevice(Hub.java:20)
    at org.usb4java.javax.DeviceManager.scanNewDevices(DeviceManager.java:155)
    at org.usb4java.javax.DeviceManager.scanNewDevices(DeviceManager.java:159)
    at org.usb4java.javax.DeviceManager.scanNewDevices(DeviceManager.java:159)
    at org.usb4java.javax.DeviceManager.scanNewDevices(DeviceManager.java:159)
    at org.usb4java.javax.DeviceManager.scanNewDevices(DeviceManager.java:159)
    at org.usb4java.javax.DeviceManager.scan(DeviceManager.java:187)
    at org.usb4java.javax.DeviceManager.scan(DeviceManager.java:274)
    at org.usb4java.javax.DeviceManager$1.run(DeviceManager.java:365)
    at java.base/java.lang.Thread.run(Thread.java:834)

is this what you need

That's exactly what I need,

That's exactly what I need, however there's nothing there that can stop it opening.

Try adding --verbose as well. The log will be much much bigger with huge amounts of extra information in there about what is happening.

So the full command:

uecide-cli --verbose --exceptions --log=file.txt

Here is the result from

Here is the result from uecide-cli --verbose --exceptions --log=file.txt have put it in a zip. but heres the thing that somehow made that uecide to come up after a while so me being a fiddler as such used it to compile that marlin sketch and it completed ok so i closed it down. restarted the uecide.exe in the same folder and it loaded and compiled ok go figure well I am over the moon it worked. now going to test chipkit sketch

Attachments: 

I'm guessing that there was

I'm guessing that there was something in your preferences file that it didn't like. However it re-wrote the preferences fixing the problem in the process. And from there it's been fine loading it.

By the way, if you turn on the "build in sketch folder" option in preferences it will cache the compiled sketch files between runs and compiling will be much faster. Without that on it only caches the files for the one session (multiple builds in the same instance of UECIDE will be fast) rather than across sessions (coming back tomorrow will be fast).

Pages