When I tried to install the SCV library, I came accross with the following problem:
"checking build system type... Invalid configuration x86_64-unknown-linux-gnu': machine x86_64-unknown' not recognized "
I copied the 'config.guess' and 'config.sub' from /usr/share/libtool/config to overwrite the existing 'config.guess' and 'config.sub' of SCV. Then I can configure further, but new problem is:
"configure: error: Target CPU type not supported: "x86_64""
I think SCV should support x86_64 target, so how can I solve this problem?
Great thanks!
Kun
The SCV does not support x86_64 in its original configuration. Please see the patch at http://thawedoutnow.blogspot.tw/2013/02/scv-for-x8664-linux-patch.html. Your system might also need GNU automake, autoconf, m4, and some development tools to generate the new configure file.
Another one is directly modifying the configure file. Please see http://boyangdu.wordpress.com/2011/11/13/systemc-setup-on-f16-x86_64/ for details
Related
I found many articles about the what I am about to ask but no precise answer. I wanted to compile a main file from a RSA library. However, this error appears and I don't know how to fix it:
The error in the image indicates that there's no such file or directory as ${workspaceFolder}boost/multiprecision/cpp_int.hpp.
The file boost/multiprecision/cpp_int.hpp is part of the Boost C++ Libraries. If Boost is not installed, as indicated in the comments above, it will be necessary to install Boost to provide the missing file and any related software to which it refers.
For information on installing Boost, take a look at the Boost Getting Started page.
Note that if you are using Linux, Boost is likely available in your system's repository (i.e. package manager, software manager, or whatever it's called on your system). If so, installing from there would probably be the easiest way to go.
If Boost did happen to be installed and the error was occuring, it would then be necessary to add the location of the Boost include files to the compilation command.
We are trying to cross compile the wxGTK (2.8.12) to our ARMv5 embedded device.
Since RAM space is limited to 64MB, we thought of not using X11.
So, we have built DirectFB and GTK+ (with gdktarget as directfb and without x).
Now, we are trying to build wxGTK with GTK+. But it seems like, it need X11 header files. Got following compiler errors:
./src/unix/utilsx11.cpp:31:22: warning: X11/Xlib.h: No such file or directory
./src/unix/utilsx11.cpp:33:23: warning: X11/Xutil.h: No such file or directory
./src/unix/utilsx11.cpp:40:22: warning: gdk/gdkx.h: No such file or directory
./src/unix/utilsx11.cpp:44: error: ‘Atom’ does not name a typeenter code here
....
Is it possible to build wxGTK with GTK+ (directfb) but without X?
Thanks,
Hari
wxGTK requires GTK+ and, while GTK+ can use different backends, notably Wayland, it's unlikely to be available on your device.
You could try building wxDirectFB instead, but wxDFB is a very alpha-quality port which hasn't been in use since quite some time, so you should be ready to do some work on it yourself in order to implement the missing parts (there will definitely be at least some).
There is a minimalist GNOME implementation based on the GTK+. It is based on the X11 and GTK+. It can be build using OpenEmbedded or probably downloaded as prebuilt WM.
Now looking at it I think you can try GNOME Embedded with wxGTK.
Recently I just used fsl-community-bsp and meta-qt5 layer to generate the cross toolchain and the rootfs. I used "bitbake meta-toolchain-qt5" and "bitbake fsl-image-multimedia-full". Both fsl-community-bsp and meta-qt5 use jethro branch.
Following are some of my questions:
In the rootfs which I put in the “riotboard”, is qt5 library already in it? Do I need to compile the source of qt5 and copy it to the board
separately?---Now it's clear, the library are inside the rootfs;
I have set up the qtcreator: device, kit, qt version, compiler, debugger, also ssh connection, but when I run the application, qt says
“This application failed to start because it could not find or load the qt platform plugin xcb, available platform plugin are: eglfs, minimal, minimalegl, offscreen”.---It seems the error is fixed by me, modifying the PACKAGECONFIG[gles2]="-opengl es2 -eglfs -qpa eglfs,,virtual/libgles2 virtual/egl";
In the Jethro branch of meta-qt5, the qtbase.inc is missing, correct? I found on the internet, that I can modify the PACKAGECONFIG[gles] value, add –qpa eglfs.---It's into the qtbase_git.bb now;
I also found that in the Jethro branch, the serialport is also missing, but in our application, we need this function to handle the serial keyboard. How can we do now?---I find it now;
If I need to compile the qt5 source and copy all the folder to the riotboard, how can I set the path in the qtcreator to find the relevant library?---No need to do this;
Thank you very much!
To enable EGLFS, in local.conf add: DISTRO_FEATURES_remove = "X11 wayland"
1.You do not need to copy the qt5 library, you could follow this wandboard qt5 implementation here
In your machine, you need to enable Qt to run eglfs platform, in /etc/profile, add export QT_QPA_PLATFORM=eglfs or when you run an application; you need to add -platform eglfs. ie. helloworld -platform eglfs
There is no qtbase.inc; You could add PACKAGECONFIG_append_pn-qtbase = " eglfs xx xxx xxxx" to enable the configuration you need
There is qtserialport_git.bb in Jethro
As said, you do not copy the libraries and sources but instead tell Bitbake to do that for you. They will be moved to the corresponding places.
I am working on a project which needs to be executed in a Linux machine that has turned out not to have the GLIBCXX_3.4.20 version of a library, but the code needs it. Is there anyway to find which part of my code (C++) asks for this version?
I read the ELF file using objdump and realdef and I found which symbol needs it:
_ZSt24__throw_out_of_rang#GLIBCXX_3.4.20 (4)
but I don't know to which part of my code can be related.
Your question is essentially a duplicate of this question.
Except in your case, it's not libc.so.6, but libstdc++.so that's giving you trouble.
Your problem is that you are compiling with new GCC, but are running on a machine with an old libstdc++.so.
You have a few options:
you can update target machine to have a new enough libstdc++.so
you can build using older version of GCC
you could use -static-libstdc++ flag to link required version of libstdc++ directly into your application. This will make a larger binary, but it will not be using libstdc++.so at all.
Note that if you link against other shared libraries that do link against libstdc++.so, your binary may not run correctly on the target machine, so this solution should be used with caution.
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.