Unexpected EOF when linking Arduino project in Eclipse on OS X - eclipse

I have been trying to link Arduino and Eclipse, and I feel like I'm close.
Where should I start looking for this?
Similar errors have been caused by extra/incomplete quote blocks (according to google searches). I have already dug through my AVR linker settings looking for quotes, but haven't had much luck.
Am I looking in the right place?
Which files should I check?
I have already looked in the file I have written myself (in this case, the basic Arduino blink program).
**** Build of configuration Release for project C64_Arduino1 ****
make all
Building target: C64_Arduino1.elf
Invoking: AVR C++ Linker
avr-gcc --cref -s -Os -o"C64_Arduino1.elf" ./C64_Arduino1.o ./CDC.o ./HID.o
./HardwareSerial.o ./Print.o ./Stream.o ./Tone.o ./USBCore.o ./WInterrupts.o ./WMath.o ./WString.o ./malloc.o ./wiring.o ./wiring_analog.o ./wiring_digital.o ./wiring_pulse.o
./wiring_shift.o -l"Arduino_Mega_2560_or_Mega_ADK" -lm -L/Users/Chet/Desktop/Chet's Shit/Side Projects/Programming/C64_Arduino1/Release -L"/Users/Chet/Desktop/Chet's Shit/Side
Projects/Programming/C64_Arduino1" -mmcu=atmega2560
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [C64_Arduino1.elf] Error 2
**** Build Finished ****
EDIT:
I have commented out all of my code (including #include's) except the main (which is empty) and I still get the error. I have set up my IDE as specified Here and also Here. Still nothing.

Looking at the actual error message:
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
I can see that the problem is most likely due to some kind of Makefile syntax error.
When you write a make rule such like:
foo:
touch foo
What make does, it first checkes whether file called foo exists already, if not, then it runs command /bin/sh -c 'touch foo'. So the line where we said touch foo should have valid shell script syntax.
Looking at the command that you ended up running:
avr-gcc --cref -s -Os -o"C64_Arduino1.elf" ./C64_Arduino1.o ./CDC.o ./HID.o
./HardwareSerial.o ./Print.o ./Stream.o ./Tone.o ./USBCore.o ./WInterrupts.o ./WMath.o ./WString.o ./malloc.o ./wiring.o ./wiring_analog.o ./wiring_digital.o ./wiring_pulse.o
./wiring_shift.o -l"Arduino_Mega_2560_or_Mega_ADK" -lm -L/Users/Chet/Desktop/Chet's Shit/Side Projects/Programming/C64_Arduino1/Release -L"/Users/Chet/Desktop/Chet's Shit/Side
Projects/Programming/C64_Arduino1" -mmcu=atmega2560
I can see that the issue is with the ' character in some of the directory paths. You should either escape it (as in "/Users/Chet/Desktop/Chet\'s Shit") or, as a quick work-around symlink or move the directory.
As a general methodology tip, you should first check whether everything works in CLI, and then move on to teaching Eclipse what commands it should run.
Also, I would consider using the tool called ino instead of make, it might just work with minimum configuration. I have had some experience replacing Arduino IDE with just a Makefile, but it gets hairy when you need to use different boards and perhaps several connected at the same time. Give ino a try, it looks quite promising.

Related

Simulink: fatal error: MQTTAsync.h: No such file or directory

I am trying to build an MQTT system on a raspberry pi. I was studying about MQTT and read about it a lot. I found a set of MQTT blocks in the Simulink Raspberry Pi Hardware Support Package that I assumed I could directly use. I configured an MQTT server and got all the right credentials and everything but I am now stuck on one part that has left me stumped.
I keep getting this error saying that "fatal error: MQTTAsync.h: No such file or directory". I have looked a lot trying to find anything that might help me but I couldn't. I don't know where to get the necessary files that I need or if there is any solution to sort this. I'm sharing the entire snippet of the error if that is of any help. Thanks in advance.
I apologize I'm not able to get to the whole error into a code block
Error executing command "touch -c /home/pi/MATLAB_ws/R2022a/C/Users/User/Documents/MATLAB/Project_RPi_ert_rtw/*.*;make -f Project_RPi.mk all MATLAB_WORKSPACE="/home/pi/MATLAB_ws/R2022a" -C /home/pi/MATLAB_ws/R2022a/C/Users/User/Documents/MATLAB/Project_RPi_ert_rtw LC_ALL=C". Details:
STDERR: In file included from /home/pi/MATLAB_ws/R2022a/C/ProgramData/MATLAB/SupportPackages/R2022a/toolbox/realtime/targets/linux/src/MW_MQTT.c:5:
/home/pi/MATLAB_ws/R2022a/C/ProgramData/MATLAB/SupportPackages/R2022a/toolbox/realtime/targets/linux/include/MW_MQTT.h:49:10: fatal error: MQTTAsync.h: No such file or directory
#include <MQTTAsync.h>
^~~~~~~~~~~~~
compilation terminated.
make: *** [Project_RPi.mk:411: MW_MQTT.c.o] Error 1
STDOUT: make: Entering directory '/home/pi/MATLAB_ws/R2022a/C/Users/User/Documents/MATLAB/Project_RPi_ert_rtw'
gcc -c -MMD -MP -MF"MW_MQTT.c.dep" -MT"MW_MQTT.c.o" -O2 -D__MW_TARGET_USE_HARDWARE_RESOURCES_H__ -DMW_CAN_BITRATE=500000 -DMW_CAN_ALLOWALLMSGS=1 -DMW_NUM_MQTT_SUBSCRIBE=1 -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DTERMFCN=1 -DONESTEPFCN=1 -DMAT_FILE=0 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DTID01EQ=0 -D__linux__ -DARM_PROJECT -D_USE_TARGET_UDP_ -D_RUNONTARGETHARDWARE_BUILD_ -DSTACK_SIZE=64 -DRT -DMODEL=Project_RPi -DNUMST=1 -DNCSTATES=0 -DHAVESTDIO -DMODEL_HAS_DYNAMICALLY_LOADED_SFCNS=0 -I/home/pi/MATLAB_ws/R2022a/C/Users/User/Documents/MATLAB -I/home/pi/MATLAB_ws/R2022a/C/ProgramData/MATLAB/SupportPackages/R2022a/toolbox/realtime/targets/linux/include -I/home/pi/MATLAB_ws/R2022a/C/ProgramData/MATLAB/SupportPackages/R2022a/toolbox/target/shared/svd/include -I/home/pi/MATLAB_ws/R2022a/C/ProgramData/MATLAB/SupportPackages/R2022a/toolbox/realtime/targets/raspi/include -I/home/pi/MATLAB_ws/R2022a/C/Users/User/Documents/MATLAB/Project_RPi_ert_rtw -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/extern/include -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/simulink/include -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/rtw/c/src -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/rtw/c/src/ext_mode/common -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/rtw/c/ert -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/toolbox/coder/rtiostream/src/utils -I/home/pi/MATLAB_ws/R2022a/C/Program_Files/MATLAB/R2022a/toolbox/target/codertarget/rtos/inc -o "MW_MQTT.c.o" "/home/pi/MATLAB_ws/R2022a/C/ProgramData/MATLAB/SupportPackages/R2022a/toolbox/realtime/targets/linux/src/MW_MQTT.c"
make: Leaving directory '/home/pi/MATLAB_ws/R2022a/C/Users/User/Documents/MATLAB/Project_RPi_ert_rtw'

Error in ./configure step in installation of libpqxx

this is a bit of a long shot but:
I'm following this guide: https://www.tutorialspoint.com/postgresql/postgresql_c_cpp.htm
But when running ./configure I get the following error:
(previous checking lines omitted for brevity)
checking for main in -lpq... yes
checking for PQexec in -lpq... yes
checking for correct C++ linkage of basic libpq functions...
sed: character class syntax is [[:space:]], not [:space:]
configure: error:
Linking a call to libpq failed in C++, even though it succeeded in C. If your
C and C++ compilers are very different beasts, this may mean that we do not have
the right options for linking with it after all.
Read the config.log file for more detailed information. Look for the last error
message, which may be several pages up from the end of the file.
And the configure.log file looks like this:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by libpqxx configure 4.0, which was
generated by GNU Autoconf 2.68. Invocation command line was
$ ./configure
## --------- ##
## Platform. ##
## --------- ##
(some lines omitted)
configure:3039: g++ -V >&5
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
compilation terminated.
configure:3050: $? = 1
configure:3039: g++ -qversion >&5
g++: error: unrecognized command line option '-qversion'; did you mean '--version'?
g++: fatal error: no input files
compilation terminated.
(some lines omitted)
configure:7629: gcc -E conftest.c
conftest.c:11:10: fatal error: ac_nonexistent.h: No such file or directory
#include <ac_nonexistent.h>
^~~~~~~~~~~~~~~~~~
compilation terminated.
(some lines omitted)
configure:8319: gcc -c -g -O2 -fno-rtti -fno-exceptions conftest.c >&5
cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C
(some lines omitted)
configure:16424: g++ -o conftest -g -O2 -L/usr/lib/x86_64-linux-gnu conftest.cpp >&5
/tmp/ccfFBf4K.o: In function `main':
/home/peter/libpqxx-4.0/conftest.cpp:44: undefined reference to `PQexec'
collect2: error: ld returned 1 exit status
(some liens omitted)
I don't believe I have any packages missing. I have the newest version of g++, psql and libpqxx installed.
I have updated and upgraded all packages on my system.
I have crawled the web for solutions to this error, but I have no clue what is wrong.
Do you have an idea where I can go from here?
There hasn't been a tarball release of libpqxx at the old spot in a long time, so the tutorial you used with its wget command to download the tarball is very outdated.
The issue you encountered looks related to this issue and appears to have been fixed in this commit:
commit 85e9336740475be25ed19924cca0961f7d844c4b
Author: Jeroen Vermeulen <jtvjtv#gmail.com>
Date: Thu Jun 1 11:39:08 2017 +0700
Fix #13: not linking to libpq.
This was that annoying interaction between autoconf, m4, GNU sed syntax,
and the shell which broke the "remove redundant -lpq options" code in
the configure script.
Solution: forget about GNU sed's "[[:space:]]" syntax, and just look for
a literal space. There aren't going to be any tabs, newlines,
non-breaking spaces, etc. there in even a moderately sane world.

Tests for libffi fail on LFS

I am working on a Linux From Scratch project and I've run into some (potential) issues. In chapter 6.49: Libffi-3.2.1, I executed the "sed", "configure" and "make" commands successfully but when I executed "make check", it appears that every test fails:
MAKE x86_64-unknown-linux-gnu : 0 * check
...stuff...
Test run by root on Fri Jul 13 23:51:21 2018
Native configuration is x86_64-unknown-linux-gnu
=== libffi tests ===
Schedule of variations:
unix
Running target unix
...a lot of failures...
FAIL: libffi.call/va_struct3.c -W -Wall -Wno-psabi -Os (test for excess errors)
FAIL: libffi.call/va_struct3.c -W -Wall -Wno-psabi -O2 -fomit-frame-pointer (test for excess errors)
=== libffi Summary ===
# of unexpected failures 685
# of unresolved testcases 685
I've been following the book pretty closely, but maybe I missed something along the way. Should I even worry about this or should I just install it anyway and move on?
Let me know if more information is needed.
Nevermind, I solved it. I basically went back and redid everything.
I usually I copy and paste the commands from the LFS book into a bash script and run it that way (if I can get a away with it). Well, apparently I forgot to write one for the diffutils package. But this seems strange to me because I wouldn't think that missing that script would cause issues with a test that seems to use DejaGNU let alone get me that far without any troubles.
Anyway, my LFS is up and running now! 😁

arm-buildroot-linux-uclibcgnueabihf-gcc: erreur: unrecognized command line option ‘-mno-tls-direct-seg-refs’

I tried to use the defconfig of raspberrypi2 of buildroot then I run the command make.Until now all things are good,but when I added some target packages then I run make I got this error:
arm-buildroot-linux-uclibcgnueabihf-gcc: erreur: unrecognized command line option ‘-mno-tls-direct-seg-refs’
this link contain all the messages that I got on my console:http://pastebin.com/mgVthm8z
The -mno-tls-direct-seg-refs option is a x86 specific option, that libselinux is trying to use with an ARM toolchain. Which obviously cannot work. Seems like a bug in the libselinux package. As Yegor said, please report this to the Buildroot mailing list or bug tracker.
I got this:
The Makefile of libselinux performs the following check:
ARCH := $(patsubst i%86,i386,$(shell uname -m))
ifneq (,$(filter i386,$(ARCH)))
TLSFLAGS += -mno-tls-direct-seg-refs
endif
Which means that if the host machine is an x86, then TLSFLAGS will
contain -mno-tls-direct-seg-refs. That command line option causes
libselinux to fail when building it for target architectures where the
compiler doesn't support that option, i.e. MIPS:
mips-img-linux-gnu-gcc: error: unrecognized command line option
‘-mno-tls-direct-seg-refs’
So to fix that problem we can set the ARCH variable to $(KERNEL_ARCH),
and then append it to the LIBSELINUX_MAKE_OPTS.
Signed-off-by: Vicente Olivert Riera
link: https://patchwork.ozlabs.org/patch/518324/

OmniORB compilation error Windows 7 64 bit

Has anyone encountered the error below when compiling omniORB_4.1.6 64-bit for windows?
'RegQueryValueEx failed - error 109'
I followed the procedure in the readme.win32 and I get linking errors in the omniDyamic, codesets etc.. So someone suggested to rebuild the omniorb_root/src/tools/win32 and copy it in bin/x86_win32/. That's what I did and when I recompile the whole omniORB, the error is as below:
../../../../bin/x86_win32/omkdepend -D__cplusplus -D_MSC_VER -DIDLMODULE_VERSION
="0x2630" -DMSDOS -DOMNIIDL_EXECUTABLE -Ic:/python27/include -Ic:/python27/PC -I
c:/python27/include/python2.7 -DPYTHON_INCLUDE=<Python.h> -I. -I. -I../../../../
include -D__WIN32__ -D_WIN32_WINNT=0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -
D_CRT_SECURE_NO_DEPRECATE=1 idlc.cc idlpython.cc idlfixed.cc idlconfig.cc idldum
p.cc idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc idl
util.cc idlerr.cc lex.yy.cc y.tab.cc
RegQueryValueEx failed - error 109
-----------------------------------------------------------------------------------------------
make[4]: Entering directory `/cygdrive/c/Software/COTS/omniORB/omniORB_4.1.6/src
/tool/omniidl/cxx/cccp'
../../../../../bin/x86_win32/clwrapper -gnuwin32 -c -O2 -MD -GS -GR -Zi -nologo
-DHAVE_CONFIG_H -I. -I. -I. -I../../../../../include -D__WIN32__ -D_WIN32_WINNT=
0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -D_CRT_SECURE_NO_DEPRECATE=1 -Focexp
.o cexp.c
RegQueryValueEx failed - error 109
I'm going to answer my own question because it seems nobody has encountered this problem, and the mailing list is so quiet.
Someone suggested to me to recompile the src\tools\win32. So that's what I did and I copied the .exe files generated to bin\x86_win32.
I then compiled all the omniORB and get the RegQueryValueEx error.
The reason for this is when you check the src\tools\win32\bccwrapper.c in the void GetMounts(void) function,
it looks for this path in the registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
When I checked that using regedit, I noticed that in the mounts->00, 01, 02, 03 etc.. keys, there are no 'unix' and 'native' string values inside those keys.
So I decided to delete all the keys and retained just the 00 and added a 'unix' and 'native' string value.
After which, I recompiled the src\tools\win32 and copied over the created .exe files to bin\x86_win32 and finally when I recompiled all the omniOrb, it started compiling (need to copy the ssl libs too) and finished successfully.
I really don't even know how the following got into my registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
Best regards,
Mark
I spent quite some time trying to compile OmniORB on windows 10 with visual studio 2017.
Assuming Cygwin64 was installed in directory
c:\software\cygwin64
, the compilation of OmniORB is quite straightforward:
open a command terminal (cmd)
in that terminal, setup the Visual environment:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
then, append the PATH (yes append and not prepend):
set PATH=%PATH%;c:\software\cygwin64\bin
then, in file config\config.mk, uncomment this line
platform = x86_win32_vs_15
in file platforms\x86_win32_vs_15, set PYTHON to target the python executable, in my case Python 3.6.5
PYTHON = /cygdrive/c/software/Python/python
finally start the compilation with make:
make export
Hope this helps.