I'm trying to implement an open source library that is built using the GNU compiler. (namely, this: https://github.com/mjwybrow/adaptagrams )
I've tried opening and building that source code using VSC++ 6, but it results in over a thousand errors due to the strict nature of the VS compiler I guess. And rather then go through every error and try fix it myself, I was wondering if it's possible to just include the .lib if it is built with the GNU compiler?
EDIT:
Included in the source code linked above is an autogen.sh file.
mkdir -p m4
autoreconf --install --verbose
automake -a --add-missing
./configure
make
Running that with Cygwin results in a few .a library files to be created, which are unusable in VS. Is it ok to just rename these to .lib files?
I've found some stuff online about how to use GCC and create a DLL, but my problem is that I don't know enough about the GNU compiler or makefiles, or the source code in general to be able to change it right now.
Does anybody have any clues on what exactly I'd need to change to get it right? Or even better, has anyone created a DLL using this source code already that would be able to pass it on to me, or let me know what I have to do?
Or could anyone point me towards a similar library that would be compatible with visual studio?
No; you can however build the .dll file with gcc and use the .dll from msvc (with either a hand-crafted include file or a properly formatted one from the beginning, with platform specific import/export macros on top).
Related
I'm attempting to cross-compile from Linux (NixOS) to Windows and encountering some frustrations.
There seem to be two parts that together are breaking the build:
Code in my Rust project requires multithreading, and as such requires a version of libpthread for Windows.
To build properly, I need a build.rs file. For some reason, Rust requires a version of libpthread for Linux for that.
What's the problem? Well, the build.rs has to be built with regular GCC and not MinGW because it needs to execute on my system. But for some reason, GCC is attempting to link to the Windows libpthread library instead of the system one, and as such is failing with an error about not supporting the library format.
(Failed) Alternatives
If I remove the build.rs, the project builds fine. Unfortunately, I need it for full functionality.
If I remove the Windows version of libpthread the build.rs builds and runs correctly, but MinGW fails with a missing library error when building the rest of the project.
Solution Paths?
Either I have to figure out why GCC's linking to the wrong version of libpthread, or I have to disable -lpthread entirely for the build.rs. I have no idea why it would need pthreads, considering for testing I stripped it down to only fn main() {}.
I have no idea where to start on either of these, and I've already spent a couple of days getting the problem down to this. I'd appreciate some help!
Can any body explain to me what does the whole sentence mean?
I know this is to set Macro BLAS_LIBS as another string.
But I'm not sure what's the "-lblas" mean and I don't know how to use it.
Similar as the following code. "-llapack"
export LAPACK_LIBS="-L$LAPACKHOME/lib -llapack"
How can the program find out the BLAS and LAPACK libraries just by "-lblas" and "-llapack" ?
Thanks for advance.
I'm not sure why you say "just by -llapack" because that's not what is happening here. Specifically, the -L option just before it specifies a directory path to add to the library resolution path. This works roughly like PATH in the shell.
For example, with the command line fragment gcc -Lfoodir -Lbardir -lfoo -lbar, you basically instruct the linker to search the directories foodir and bardir for the library files libfoo.a and libbar.a.
The -l option is described in GCC: Options for Linking and -L and friends in the following section GCC: Options for Directory Search.
This build arrangement -- configure the build to show where the required files are before compiling -- is common for libraries, where if a user has already downloaded and compiled a required library for some other project, they don't need to rebuild it; they can just point the compiler to wherever they already have the stuff needed for this project.
Building your own libraries is becoming increasingly unnecessary anyway, as prepackaged binaries of most common libraries are available for most systems these days. But of course, if you are on an unusual platform, or have specialized needs which dictate recompilation with different options than any available prebuilt binary, you will still need to understand how to do this.
I wonder if anyone did managed to build the fresh SDL2 with the toolchain of the Android NDK(r8d).
SDL2 seems to be very close to the release (since yesterday it isn't "UNDER CONSTROCTION anymore: http://hg.libsdl.org/SDL/rev/0a3d2ec7af6d). It comes with an Android.mk and just compiles fine following the instructions in the bundled README.android file. My question is whether there's really no working automake based build is available or will be available to compile it on Android, or something's wrong with my toolchain setup?
I have installed the NDK toolchain following the instructions of the documentation located at $NDK/doc/STANDALONE-TOOLCHAIN.html. I'm using gcc 4.6. Here's one environment i use:
#!/bin/sh
export TOOLCHAIN=$HOME/Android/android-14-arm
export PATH=$TOOLCHAIN/bin:$PATH
export SYSROOT=$TOOLCHAIN/sysroot
export CROSS_COMPILE="arm-linux-androideabi"
export CC=$CROSS_COMPILE-gcc
export CXX=$CROSS_COMPILE-g++
export CPP=$CROSS_COMPILE-cpp
export CFLAGS="-march=armv7-a -mfloat-abi=softfp -mfpu=neon"
export LDFLAGS="-march=armv7-a -Wl,--fix-cortex-a8"
echo "Compiler set up for ARM 14"
The configure params:
./configure --host=arm-linux-androideabi --prefix=$SYSROOT/usr/local
With the same configuration i successfully built libjpeg-turbo v8 and SDL_image.
The configure script recognizes the cross-compiler, and builds the makefile, however, it finds X11 support, can't see the OpenGL ES... The make fails:
In file included from /usr/include/features.h:378:0,
from /usr/include/sys/types.h:27,
from ./include/SDL_stdinc.h:35,
...
I checked the configure log, i have no idea where the "/usr/include" comes from.
But in fact, the generated makefile adds that line in the EXTRA_CFLAGS to the compiler.
The NDK doc refers the --with-sysroot=$SYSROOT as optional, i've included it to see if it solves the problem, but that didn't help.
As a last effort i manually edited the Makefile, fixing that reference, and now the compiler complained about X11.h.
AFAIK Android has nothing to do with X11, so i guess the whole build-tree completely inappropriate to use with NDK.
I have also tried a different configuration, found in an older thread here.
Neither defining -DANDROID -mandroid -fomit-frame-pointer nor changing back to -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb" solved the problem.
On previous projects, i had to refresh config.guess, and config.sub in order to get my compiler recognized. SDL doesn't seem to use those. Furthermore no Makefile.ac or Makefile.am comes with SDL to work with, and no templates for other platform could be used for a good starting point to create my own makefile. Additionally, i've never had to deal with makefiles, i really have no chance to sort out these problems. Even if it succeeds, i will probably need a configure tool as well, since i have no idea how ndk-build manages to install SDL2 without configure scripts.
Compiling the SDL sources with the project together is the only working - but ugly solution. I would like to deploy the necessary lib and header files by make install.
I hope the solution is something really easy and obvious thing that i just didn't think about...
This issue has been fixed at http://hg.libsdl.org/SDL/rev/4e57cfd9fca8 and expected for the 2.0.4 release. Note there are newer revisions with some related fixes about defines.
I currently compiled a set of source code in C in Linux and the output is a *.o file which is a object file. This supposedly does image compression. Now I want to use/test this in Android.
Is this possible? I have only tried NDK examples from the Android NDK developer side. Have not came across any reference on how this can be done.
Thanks In Advance,
Perumal
You don't run object code files (*.o). You would need to turn it into an executable. To do this, assuming you are using GCC you would run gcc file1.o file2.o -o executable which would convert a two file program with file1.o and file2.o into an executable called executable.
Object files (ending in .o) usually contain code that is incomplete. For example, if your program uses some library to print something on screen, to produce an executable, you must link your compiled code (the .o file) with the library, so that when the operating system loads the executable knows all the code that will be used. You do this linking with a linker (such as ld in Linux, or /system/bin/linker in Android). In your case, it's easier to let gcc call the linker for you, as Jalfor notes.
The answer is Yes. But you have to do some fair amount of work to see it running on Android.
1) If you are compiling on Linux, it means the object file or the final executable is being built for the x86 or AMD processor(Mostly). But mostly all the mobile devices have ARM processors running on their phones. So, though you have an executable you will not be able to execute it in ANdroid if it is not built for ARM Cpu. This is what android NDK does exactly.
2) So, we have to build the same code again for Android(ARM), for which we need a cross-compiler and the source code of the object files you are talking about.
3) If you have source code avilable, you can do 2 things again.
To include it in JNI folder, build the shared library and then do the
stuff of calling and all.
Build the code into an executable(Note you need to have main
inside the code) using the android NDK and then push the executable inside Android using
adb.
Now finally you can login and then check the result. In case anything is not clear, please do let me know. I wont mind explaining. Thanks..
I want to build XZ Utils with MSVC++, but xz utils uses a Gnu Autoconf Script. Is there a way to import a whole autoconfed project into MSVC++, then build it? If not, is there a way to run the Gnu Autoconf script for MSVC++, then after that, just take all the source files, as well as config.h, then build it?
FYI XZutils is written in C99 and will not compile under MSVC without massive changes. Just build in MINGW and link to the static lib or dll.
As far as I know, not really. You could try installing MSYS and seeing what the support for cl.exe is like in the configure script:
./configure CC=c:/path/to/cl.exe CXX=c:/path/to/cl.exe
Last time I checked, the support was rather immature, but it could be worth a shot. On the other hand, since xz-utils is written in straight C, what does it matter which compiler you use? Build it with MinGW and link against it with visual studio.