I've been building my own c++ linux application in vs2017, using the built in tools that connect to my virtual ubuntu VM. I have gotten to a point where I want to integrate protobuf into my project, but I am running into issues as to how to do so.
I have installed the protobuf libraries and compiler on my VM using Google's UNIX C++ installation guide. And I am able to compiler without issue. After I compiled one message, I brought the files back over to my windows side so that I can bring them into my VS project. However that causes all sorts of errors, mainly:
undefined reference to 'google::protobuf::internal'
So I went through a previous Stack Overflow post where the user ran the following command on the VM:
pkg-config --cflags --libs protobuf
and the took the text in that output, and put it into his Linker > All Options > Library dependencies in his VS project on the windows side. For me, that was:
-pthread -lprotobuf -pthread -lpthread
However, when I compile, I get cannot find. I've been trying to find out what are the best practices when doing linux development through VS2017, and wanting to use protobuf. Any help on how to get that entire chain working would be great.
Related
I am trying to compile a 32-bit application on 64-bit Debian Stretch. I have compiled several other applications successfully this way, but one app that uses the pcap library is giving me problems. There does not seem to be a 32-bit version of this library anywhere for my platform.
Problem description
When I try to link my application, like this:
g++ (...objectfiles-and-options...) -m32 -o myapp -lpthread -lpcap
I get the error
/usr/bin/ld: cannot find -lpcap
I checked, and there is indeed no libpcap.so (or variant thereof) in /usr/lib32. However, all other libraries I am using is present there (like libpthread). I tried to create soft-links to the 64-bit pcap-libraries in there, just in case they should be multi-platform compatible, but that only resulted in "skipping incompatible /usr/lib32/libpcap.so when searching for -lpcap".
I've installed libpcap-dev, libc6-dev-i386, gcc-multilib and g++-multilib (obviously, since cross-compilation works fine for all applications that does not use libpcap). I would suspect there should be a libpcap-dev-i386 I could install, but there does not seem to be one.
Perhaps I should mention that the application compiles and links successfully as 64 bit.
Does anyone know what I am missing here?
You can compile libpcap yourself. It's probably the better solution than depending on packages.
Use configure for 32bit architecture and than give your compiler LDFLAGS pointing to your lib or install it in /usr/lib32/
Dear programmers and developers,
I really want to try out GTK+ 3 on windows. Therefore, I read the official GTK+ download explanations at https://www.gtk.org/download/windows.php and installed everything with MSYS2.
Now I have a lot of files in my mingw64 subdirectory of my MSYS2 folder.
The question: How do I include all of them right? How do I link to GTK+ with all it's dependencies? I know there is a magic pkg-config attribute for the Linux C/C++ compiler, but unfortunately I am really not interested in compiling my projects in MSYS2. I am willing to use a simple MinGW (64) compiler.
Can anybody help me using the .a's, .h's and .dll'a that MSYS2 generated with a simple MinGW 64bit compiler for a stupid C++ project?
It would make me extremely happy!
Darth Moon
€edit: I actually have downloaded a precompiled GTK+ version from https://www.dropbox.com/sh/8d1qbh5dsp044on/AAB63l5I1eZks-QqjH6HXUJHa. Unfortunately, it is only 32bit but I will soon try to compile the whole GTK+ project on myself like this guy at https://github.com/Wesley-Chan/GTK-for-Windows did.
But if anybody has any idea how to build GTK+ in a smooth way under windows (especially for 64bit), please let me know! I really enjoyed the GTK+ example application and I really want to make my own ones!
I was able to successfully compile a GTK3 program in a MinGW 64-bit shell from MSYS2. First I installed the GTK3 package:
pacman -S $MINGW_PACKAGE_PREFIX-gtk3
Then I compiled the first example program from this page using the following command:
gcc test_gtk.c $(pkg-config gtk+-3.0 --cflags --libs)
Then I ran ./a.exe and it created a window.
If you are getting "undefined reference" linker errors, it means your Makefile is not linking your program to all of the correct libraries, or the order of the inputs to the linker is wrong.
I'm trying to use the Canon EDSDK (latest version, v3.6 as of writing) in a simple, C++, command-line program on macOS (Sierra 10.12.6). I wish to utilize a simple Makefile environment and the usual apple compiler tools (llvm-clang) and avoid Xcode or any other heavy-weight IDE. The samples included with the SDK are all Xcode centric so I've had to roll my own here.
At present, I am able to compile a program to init the SDK and list connected cameras. As soon as I execute any EDSDK command however, I am getting a dynamic linking error:
Error loading /Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG: dlopen(/Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG, 262): no suitable image found
Did find: ... snip ... mach-o, but wrong architecture
The same error lists twice (both for DppCoreG). Upon examination, DppCoreG is compiled for 64bit architecture:
file /Library/Frameworks/..snip../DppCoreG
/Library/Frameworks/..snip../DppCoreG: Mach-O 64-bit bundle x86_64
However, there are other critical parts of the EDSDK that are compiled for 32bit architecture only:
file /...snip.../DPP.framework/DPP
/...snip.../DPP.framework/DPP: Mach-O dynamically linked shared library i386
How do I resolve this? The path of least resistance so far is to compile to i386 architecture explicitly (and the documentation explicitly states EDSDK is not 64-bit compatible). All is well except this one dynamic linking error (and in fact everything I've tried so far, which is just listing connected cameras, seems to work okay) but it is something I'm sure I can't continue to ignore or allow to persist in a production version of this project.
Here's a minimal example to cause the DYLD error:
#include <EDSDK.h>
#include <EDSDKTypes.h>
#include <EDSDKErrors.h>
int main(int argc, char** argv) {
EdsInitializeSDK();
EdsTerminateSDK();
return 0;
}
And probably more informative is the command to compile:
c++ -D __MACOS__ -g -arch i386 -I./deps/mac/include -framework DPP -framework EDSDK -o min min.cpp
I have the headers in the local include directory shown in the command and the frameworks installed under /Library/Frameworks.
Note that the c++ command is Apple LLVM version 8.1.0 (clang-802.0.42)
I've concluded that this is just an error on the part of those that deliver the EDSDK for mac. They should be compiling this particular bundle as a universal binary, not a 64bit binary. You can work around the problem by simply removing the offending bundle. It appears to just be a plugin and removing it does not seem to immediately affect the SDK. Assuming you have installed the EDSDK framework in /Library/Frameworks then just do this:
sudo rm -rf /Library/Frameworks/EDSDK.framework/Versions/Current/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle
Enter your password when prompted (this assumes you are an admin account) and it will delete the offending plugin.
I have to believe that there may be consequences for removing this plugin at some point and if anyone knows more about this particular bundle/plugin and can explain what removing it will do I'd appreciate the additional insight.
In addition to #OllieBrown answer, I found in Xcode building for MacOS I had an additional item to remove to stop the link warnings.
link warning- EDSDK.framework/Versions/Current/DPPLibCom.bundle/Contents/MacOS/DPPLibCom: mach-o, but wrong architecture
removing EDSDK.framework/Versions/Current/DppLibCom.bundle stopped the warning.
Since the 3.x version there is a split between intergrated versions of DPP RAW capabilities. The original DPP works in x86 mode only and allows inspection and conversion of CR2 files on cams up until a certain models. See the API doc for the list. For recent camera models which rely on the new 64bit DPP engine (v4+?, dppcoreg) you would need x86_64 bit build so it dynamically links to use the latest features. Quite some (Raw) features are dropped, and gradually make their way back in in beta state.
In order to use nzmqt on Qt5 (Windows) I downloaded and compiled ZeroMQ 3.2.5 as described on GitHub. My Qt5 application compiles fine but it doesn't run: it complains about the entry point of libstdc++-6.dll.
I guess it's due to the different version of MinGW used to compile ZeroMQ (the one included in the RubyDevKit) and my application.
Thus, I'm trying to compile ZeroMQ with the MinGW which comes with Qt5... Unfortunately it's not enough to run mingw32-make from the Qt5 folders because it doesn't accept the "fail" command in the Makefile:
$(RECURSIVE_TARGETS):
#fail= failcom='exit 1'; \
This is beyond my knowledge.
I'm wondering if anyone was able to use nzmqt with ZeroMQ 3.2.5 under Windows and Qt5.
I am having a problem with cross compiling google v8 libraries for raspberry pi, and constantly getting "Illegal instruction" error when compiling official sample from site. These are the steps i followed:
Downloaded cross compile https://github.com/raspberrypi/tools/
Cloned v8 git https://chromium.googlesource.com/v8/v8.git
Exported CXX LINK point to arm-linux-gnueabihf-g++ from cross compile tools.
run make arm.release armv7=false hardfp=on snapshot=off armfpu=vfp armfloatabi=hard -j5
Copied generated executable shell and d8 from out/arm.release directory to pi (Raspbian kernel version 3.6.11) and it WORKS.
These steps prove that cross compilation toolchain is functional.
Problem occurs when trying to run other cross-compiled software that is linked to v8 libraries. For example sample code from https://developers.google.com/v8/get_started#intro.
Code is cross-compiled with this command (same as example, just changed compiler)
arm-linux-gnueabihf-g++ -I. hello_world.cc -o hello_world -Wl,--start-group out/x64.release/obj.target/{tools/gyp/libv8_{base,libbase,snapshot,libplatform},third_party/icu/libicu{uc,i18n,data}}.a -Wl,--end-group -lrt -pthread
When i copy that code to pi and run it i get SIGILL (Illegal instruction).
Note: cross compiled software that doesn't use v8 libraries works fine. Also x64 v8 libraries on host computer work fine.
On newer kernel versions shell and d8 were also throwing SIGILL but than i switched to older version 3.6.11 (problems with newer kernel https://groups.google.com/forum/#!topic/v8-users/IPT9EeYK9bg) and they started working, but compiled sample code is still showed same issues.
Did anyone have similar experience? Any suggestion on how to overcome this problem?
I found a solution thanks to post on v8 google group. https://groups.google.com/forum/#!topic/v8-users/LTppUbqNrzI
Problem was in make arguments it should be.
make arm arm_version=6 armfpu=vfp armfloatabi=hard