Hello StackOverflow Community,
Recently I have been noticing that my Arduino IDE has simply been failing to actually be able to compile and run to any board, from the TTN Uno (which is a smaller Arduino Leonardo), ESP8266 (both in module and WeMos), to the Arduino Uno (R3 SmD version).
I enabled verbose output from the compilers inside of the IDE's preferences. and the lines that it crashes on is when the file .o files get compressed into the final .hex that the avrdude (or esptool) finally pushes into the programmable flash that the boards utilize to operate.
Linking everything together...
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-gcc" -w -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections -mmcu=atmega328p -o "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309/sketch_jun27a.ino.elf" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\sketch\sketch_jun27a.ino.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\DHT-sensor-library\DHT.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\DHT-sensor-library\DHT_U.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\appData.pb.c.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\deviceData.pb.c.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\pb_common.c.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\pb_decode.c.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\pb_encode.c.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\CayenneLPP.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\TheThingsMessage.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\TheThingsNetwork\TheThingsNetwork.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\Timer\Event.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\libraries\Timer\Timer.cpp.o" "C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309/core\core.a" "-LC:\Users\JTamez\AppData\Local\Temp\arduino_build_806309" -lm
wiring.c.o (symbol from plugin): In function `__vector_16':
(.text+0x0): multiple definition of `init'
C:\Users\JTamez\AppData\Local\Temp\arduino_build_806309\sketch\sketch_jun27a.ino.cpp.o (symbol from plugin):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
I am not sure why wiring.c is now causing issues when it has consistently worked for so long. Is this a side effect of corruption, or a external library affecting it? All the Libraries I am using are listed below:
Using library DHT-sensor-library at version 1.3.0 in folder: C:\Program Files (x86)\Arduino\libraries\DHT-sensor-library
Using library Adafruit_Sensor at version 1.0.2 in folder: C:\Program Files (x86)\Arduino\libraries\Adafruit_Sensor
Using library TheThingsNetwork at version 2.5.10 in folder: C:\Users\JTamez\Documents\Arduino\libraries\TheThingsNetwork
Using library EEPROM at version 2.0 in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\EEPROM
Using library Timer in folder: C:\Program Files (x86)\Arduino\libraries\Timer (legacy)
Any help would be greatly appreciated.
I apologize everyone, I figured out that a method I created called 'init()' was interfering with init() inside of wiring.c
Related
My development environment consists of a Teensy 3.5, PlatformIO, and CLion. How can I make use of the standard Arduino Keyboard library?
I'm working on a project to convert a previously RS422-based device to USB. Earlier on, I used the (sadly rather horrible) Arduino IDE so I know that my code for when to send which keystrokes should work; the problem is getting the new IDE and compiler to understand the dependencies.
All along, I've been using the Serial interface to provide debug output, so I know that Serial works just fine. Ditto for using the Keyboard library from within the Arduino IDE.
However, after switching to CLion and adapting to the PlatformIO framework, I ran into problems when it came time to include the Keyboard library.
The line
#include <Arduino.h>
resolves to the file ~/.platformio/packages/framework-arduinoteensy/cores/teensy3/Arduino.h which itself seems to simply be a shim for ~/.platformio/packages/framework-arduinoteensy/cores/teensy3/WProgram.h which implements the expected Arduino functionality.
However, the line
#include <Keyboard.h>
resolves to the file ~/.platformio/packages/framework-arduinoteensy/cores/teensy3/Keyboard.h which quite frankly states that it is an empty Keyboard.h file, for compability with Arduino's Keyboard examples and does not implement anything.
I have been trying to find ways of importing the original Arduino library (by way of platformio.ini, but it seems to depend on HID and PluggableUSB that I simply cannot find.
Here is my current platformio.ini file:
[env:teensy35]
platform = teensy
board = teensy35
framework = arduino
; Avoid the Teensy loader gui app
upload_protocol = teensy-cli
lib_deps =
Keyboard
and this is the build output I am getting:
====================[ Build | Production | teensy35 ]===========================
~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/223.8617.54/bin/cmake/linux/x64/bin/cmake --build ~/code/teensy-axial/cmake-build-teensy35 --target Production -j 6
[1/1] cd ~/code/teensy-axial && platformio -c clion run -eteensy35
FAILED: CMakeFiles/Production ~/code/teensy-axial/cmake-build-teensy35/CMakeFiles/Production
cd ~/code/teensy-axial && platformio -c clion run -eteensy35
Processing teensy35 (platform: teensy; board: teensy35; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/teensy/teensy35.html
PLATFORM: Teensy (4.17.0) > Teensy 3.5
HARDWARE: MK64FX512 120MHz, 255.99KB RAM, 512KB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES:
- framework-arduinoteensy # 1.157.220801 (1.57)
- toolchain-gccarmnoneeabi # 1.50401.190816 (5.4.1)
LDF: Library Dependency Finder -> [redacted for StackExchange]
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 94 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Keyboard # 1.0.4
Building in release mode
Compiling .pio/build/teensy35/src/AxialKeyboard.cpp.o
Compiling .pio/build/teensy35/src/main.cpp.o
Compiling .pio/build/teensy35/lib882/Keyboard/Keyboard.cpp.o
Compiling .pio/build/teensy35/lib882/Keyboard/KeyboardLayout_da_DK.cpp.o
Compiling .pio/build/teensy35/lib882/Keyboard/KeyboardLayout_de_DE.cpp.o
In file included from .pio/libdeps/teensy35/Keyboard/src/Keyboard.cpp:22:0:
.pio/libdeps/teensy35/Keyboard/src/Keyboard.h:25:17: fatal error: HID.h: No such file or directory
*************************************************************
* Looking for HID.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:HID.h"
* Web > https://registry.platformio.org/search?q=header:HID.h
*
*************************************************************
compilation terminated.
[...]
I have obviously visited the registry as suggested and tried to implement both mitchman631/HID and levi--g/USBLibrarySTM32 but still I end up missing either HID or PluggableUSB dependencies, and I cannot find a PluggableUSB.h file anywhere. Surely, there must be something fundamental I am not seeing?
Amending platformio.ini with the path to the Arduino libraries did not resolve the error.
lib_extra_dirs =
/usr/share/arduino/libraries
so I removed these lines again.
I have also tried enabling the --verbose option by copying the command from the above output:
~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/223.8617.54/bin/cmake/linux/x64/bin/cmake --verbose --build ~/code/teensy-axial/cmake-build-teensy35
but oddly that results in
CMake Error: Unknown argument --build
even though it should know it:
~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/223.8617.54/bin/cmake/linux/x64/bin/cmake --help | grep build
cmake [options] <path-to-existing-build>
cmake [options] -S <path-to-source> -B <path-to-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
-B <path-to-build> = Explicitly specify a build directory.
-G <generator-name> = Specify a build system generator.
--build <dir> = Build a CMake-generated project binary tree.
I suspect my question is similar to this one, although my problem is with adding any library.
I have a c++ program, which contains two classes. one of them is using libssh and some of its functions and another one is for calculating cpu usage. there is a link of how I a built and added libssh:libssh's functions couldn't be found on qt my program works fine. now I want to build a .so library out of it to use in other programs. first I made two .o file like this:
gcc -c -fPIC info.cpp -o info.o
gcc -c -fPIC cpuusage.cpp -o cpuusage.o
and I made a .so from them:
gcc -shared -o libsmc.so info.o cpuusage.o
whenever I want to use libsmc.so, I include info.h, but the problem is that libssh functions cannot be found. I think I have to add libssh statically to my project. but I don't know how to!
Ps:I read this explanation :Using a shared library in another shared library , but this is for linking shared libraries that have been used in a program via command line, I don't wanna compile program with command line and want to link libraries constantly.
To build a C/C++ software using external libraries, I would really recommend to use a build system instead of typing commands manually.
The most used build system for C++ is CMake (https://cmake.org/), which is well supported by Qt, but there are many other build systems existing. Another is QMake, which is Qt's build system.
If you are using an IDE, like QtCreator or Microsoft Visual Studio, CMake is integrated as well. There are plenty of tutorials and example to use CMake for a project (e.g. https://mirkokiefer.com/cmake-by-example-f95eb47d45b1), even though the learning curve is not as steep as I would want.
But if you still want to use command line (or to debug the command line generated by CMake): When linking against a library, you need to:
Give the include path to the compiler, i.e. the path where the .h of the external library can be found. With gcc, this is done with -I, e.g. "-I/usr/lib/mylib/include".
Give the library folder and name to the linker, i.e. the path where to find the compiled library, as well as its name. With gcc, this is done with -L for the path and -l for the name. Check the gcc manual for more details about these commands.
And if you want to use CMake, then you can use the functions:
target_include_directories(..)
and
target_link_libraries(..)
I need to compile the rtree extension for SQLite from source code. The readme includes these instructions:
The easiest way to compile and use the RTREE extension is to build
and use it as a dynamically loadable SQLite extension. To do this
using gcc on *nix:
gcc -shared rtree.c -o libSqliteRtree.so
You may need to add "-I" flags so that gcc can find sqlite3ext.h
and sqlite3.h. The resulting shared lib, libSqliteRtree.so, may be
loaded into sqlite in the same way as any other dynamicly loadable
extension.
Problem I'm having is that I'm on Windows, not Linux, and so need to use MSVC. I tried:
cl rtree.c -link -out:libSqliteRtree.so
This gave cannot open include file errors until I found the various .h files it was complaining about and moved them into the same directory. Now, however, it's gotten to:
/out:rtree.exe
-out:libSqliteRtree.so
rtree.obj
Creating library libSqliteRtree.lib and object libSqliteRtree.exp
LINK : fatal error LNK1561: entry point must be defined
I admit I have pretty much zero clue what I'm doing in a compiler, and I'm not sure where to go from here to resolve its problem. Am I "translating" the compiler flags correctly from GCC to MSVC? What else can I tweak to try to get the SQLite extension out of the source code? Should I beg a favor from a developer on ateam with a Linux server and ask them to do it for me?
Thanks to Shawn for commenting to look at the SQLite Run-Time Loadable Extensions documentation, which had more information in it:
To compile on Windows using MSVC, a command similar to the following will usually work:
cl YourCode.c -link -dll -out:YourCode.dll
So for my situation: cl rtree.c -link -dll -out:libSqliteRtree.dll worked.
How does one view the actual compiler calls (calls to the clang compiler in my case) that ninja generates when processing a build.ninja file?
Currently, I just get a bunch of summaries like this:
[1/47] Building C object CMakeFiles/proj.dir/home/me/projects/proj/src/native_src.c.o
Whereas I would like to see the actual clang command line call for each source file compile.
The answer is:
ninja -v
In my particular use case I am building a native library for an android project, in which case android studio installs ninja to a directory which isn't on the PATH, i.e.
~/Android/Sdk/cmake/3.6.3155560/bin/ninja -v
Running ninja with this option outputs all the clang compiler calls so you can check they are as you expect
source -> https://ninja-build.org/manual.html#_extra_tools
Using glew, I'm trying to link the simple program
#include </usr/include/GL/glew.h>
int main (int argc, const char * argv[])
{
glewInit();
return 0;
}
in XCode 4, under OSX Lion, which reports the error:
ld: library not found for -lGLEW.1.7.0
Command /Developer/usr/bin/clang++ failed with exit code 1
however, the error output also reports the following flags for the linker
-mmacosx-version-min=10.7 -L/usr/lib -lGLEW.1.7.0 -lglfw -framework OpenGL -framework Cocoa
and indeed, libGLEW.1.7.0 does reside in /usr/lib
Moreover, if I try to build the program by hand, with
gcc -L/usr/lib -lGLEW.1.7.0 main.cpp
I get an a.out file without any errors reported (which if run causes a segmentation fault, but maybe that's to be expected)
Any ideas on what might be causing XCode to produce this error and how it could be avoided?
Built and installed GLEW myself and had the same issue with plain gcc inside a makefile on OS X with compilation of code from https://github.com/jckarter/hello-gl
The following steps resolved the issue:
I found my GLEW libs (libGLEW.a and libGLEW.dylib) installed in /usr/lib directory (it definitely was there owned by root with r permissions for others). Tried to change GLEW_LIB variable from the makefile to /usr/lib but still got ld: library not found for -lGLEW
after that I tried to link compiled program against static library directly (without -l flag) - for that I removed -lGLEW from gcc command and changed it to direct link t library /usr/lib/libGLEW.a - it compiled and linked fine
Ok - it's a work around to try first
Then I created two links to my libraries with the following commands:
ln -s /usr/lib/libGLEW.a /usr/local/lib/libGLEW.a
ln -s /usr/lib/libGLEW.dylib /usr/local/lib/libGLEW.dylib
and finally got it working with original makefile (only changed GLEW_LIB variable to /usr/local/lib).
Probably GLEW's make install should place libraries to /usr/local/lib directly.
(I have removed this from an edit to the question and posted it as an answer, as per leppie's suggestion)
I might have found the answer in some details I had considered unimportant in my original post. So here goes, in case others might encounter a similar problem.
Apparently, XCode4 projects use clang++ by default, which in the link phase accepts a parameter -isysroot (which apparently ld does not accept).
Now, if in your build settings (as was my case) your Base SDK has been defined as something other than Current Mac OS, the parameter -isysroot will be introduced with the value of a directory pointing to that SDK, thus (this is my guess) prepending this to all other lib directories you might be including with -L.
In my case, -L/usr/lib was effectively turning into -L/Developer/SDKs/MacOSX10.7.sdk/usr/lib which does exist and did not contain libGLEW, hence the error "library not found"