Trying to compile Xfoil and plotlib
The fortran files are compiled with MinGW gfortran 4.5.0, and I compiled W32win.c with MSVC (2008/15.00).
During linking with GCC I receive error:
../plotlib/libPlt.a(W32win.o):(.text+0x1469): undefined reference to `_chkstk'
../plotlib/libPlt.a(W32win.o):(.text+0x1509): undefined reference to `_chkstk'
Any suggestions on how to resolve?
The reason I am trying to use MSVC, is that when I compiled plotlib with gcc only, the plot window does not operate properly, and displays only a black screen.
If you use the command-line MSVC compiler, cl.exe, use the option /Gs to prevent it from emitting the calls to _chkstk.
Otherwise that is probably a check-box in the project options part of the MSVC GUI.
Either way, recompile W32win.c with the needed compiler setting and you should be one step farther along your path.
Related
I am following this site to compile OpenCV for ARM.
It could not find my compiler so i hardcoded it into cmake file
find_program(CMAKE_C_COMPILER NAMES arm-linux-gnueabi-gcc-4.7)
find_program(CMAKE_CXX_COMPILER NAMES arm-linux-gnueabi-g++-4.7)
set(ARM_LINUX_SYSROOT /usr/arm-linux-gnueabi CACHE PATH "ARM cross compilation system root")
It compiles to aproximately 50% and then throws the following error:
Linking CXX shared library ../../lib/libopencv_viz.so
/usr/lib/libvtkCharts.so.5.8.0: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I am not every experienced in cross compilation (or straight compilation for the matter). How do i fix this?
I think it is a mismatch between libopencv_viz and libvtkCharts. Some of your 3rdparty libs are built for another platform. These libraries themselves must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which they are intended to be used.
Compiling OpenCV 2.4.10 worked for me. I did not have any preferred version. If you want to compile v3.0 see #Kornel's answer, that suggests to leave viz library out of compilation.
Use this command to checkout v2.4.10
git checkout 2.4.10
I'm trying to use the 64-bit MinGW from http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/ but when I compile a program with it, the resulting executable fails when a DLL isn't available.
How do I get this compiler to do static linking with the standard library?
Or is there another distribution of 64-bit MinGW that I should be using instead?
The g++ switch is supposed to be
-static
See
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html.
-static
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
You should post the command line, that you use in order to compile/link, in order to get more help if this does not work for you.
I wrote a very simple ncurses program to be run in BusyBox environment. However, it seems like that I cannot get my program to compile with everything. I used:
g++ menu.cpp -ohello -lncurses --> Works fine
g++ -static menu.cpp -ohello -lncurses --> Undefined reference to SP (many times)
I found this question but it ignores linking to ncurses. I need a very single executable. My targeted environment is fixed, so I do not concern portability.
You should paste the exact compiler calls and the exact error messages that you are getting.
Do you have a static version of the ncurses library?
More importantly, do you have a static version of the ncurses library compiled for your target environment? For example your target environment may be using ulibc instead of glibc or it could even be a whole different platform (hint: tell us what your target platform is).
Are you certain that you are compiling with the right flags? The compiler flags that you are showing seem more suited to compiling an application for use in the build host environment...
I have a shared library which is supposed to export only one function which is marked with __attribute__ ((visibility ("default"))). It also links with another static library (fftw), and
#include<fftw3.h>
is preceded with:
#pragma GCC visibility push(hidden)
The linker command used:
g++.exe -fvisibility=hidden -shared -o mylib.dll -Wl,--out-implib,mylib.dll.a -Wl,--no-whole-archive libfftw3.a libfftw3_omp.a -lgomp
Now the resulting library is huge and if I check the exported functions it includes ALL fftw functions, and ALL function from my files. It looks like mingw ignores visibility options. I read that previously it gave warning about -fvisibility, but now it compiles with no warnings whatsoever.
Does mingw and gcc 4.6.1 support visibility flags? If yes, how do I get rid of all unnecessary stuff in my shared library?
Mingw is a Windows port of GCC toolchain but Windows dll are not Linux so. Especially the link part is different. To specify the visibility with MingGW you have to go the Windows way and annotate your classes and functions with :
__declspec(dllexport) while compiling the library
__declspec(dllimport) while linking
If you want multiplatform support for the GCC toolchain you can add a header in your project doing that for you. For a step by step example and lots of details have a look at GCC's visibility guide.
Windows PE object files do not have visibility attributes. The closest is dllexport/dllimport, but that's only for shared libraries (DLL's). So either you don't mark all FFTW functions with __declspec(dllexport), and hope linking the static library does The Right Thing (tm), or you take care not to link to FFTW if linking with your library.
It should warn about bad visibility attributes, perhaps you need to turn up the warning level -Wall -Wextra -pedantic).
For some reason, I should use gcc to compile a C file, then link against Visual C++ 2008 project.
(I used the current latest gcc version: cygwin gcc 4.3.4 20090804.)
But there is one problem: gcc always allocate a big array with _alloca,
and VC linker can't resolve the symbol __alloca.
for example,
int func()
{
int big[10240];
....
}
this code makes the _alloca dependency although I didn't call the _alloca function explicitly.
(array size matters. if i change 10240 -> 128, everything ok)
I tried gcc option -fno-builtin-alloca or -fno-builtin, but no luck.
Is it possible to make gcc not to use _alloca ? (or adjust the threshold?)
Best thing to do would be to compile all code with VC++. If that's not possible..
You should use the mingw gcc instead of the cygwin one. It's designed to output code that will be linked against the VC++ runtime, not the cygwin libraries. In particular, it will call the VC++ runtime function __chkstk instead of __alloca.
You could just write your own _alloca routine and link against that. Look at the gcc library source to see what it's supposed to do.
It looks like _alloca has been deprecated by Microsoft and is no longer in their runtime libraries after VS2005. Newer runtime libraries support _malloca.
Your options don't look good. You can try to build with VS2005 instead. Perhaps cygwin has an option where you can tell it you are using a newer runtime library (and if they don't support that yet, you could file it as a feature request).
some related discussions:
cygwin: gcc and alloca
GNU Compiler Collection (GCC) Internals
gcc and alloca