I am compiling an app for 32bit machines since the creator of the app made it 64 bit. I made sure all the libraries and DLLs are 32bit, which they are. I have an issue when I compile, however. When I compile using sh make.sh, I get an error when it gets to the GCC building part. make.sh just makes sure that all the needed libraries are there for this project. There's no errors in the Makefile, make.sh, or any of the C++ files. I've been wasting hours trying to figure this out.
Here's a screenshot if it helps:
Needed to enable -D_WIN32 os flag in make.sh.
Related
I'd like to compile a Haskell project with a .cabal file under windows.
I have installed the Haskell Platform and Cygwin. One of the dependancies is time, which fail to build during the cabal install command.
The error message is the following:
checking for gcc... C:\PROGRA~1\HASKELL~1\826561~1.1\mingw\bin\gcc.exe
checking if the C compiler is working... no
configure error: C compiler cannot create executable
So I downloaded another gcc withing Cygwin that, I suppose, will work better.
However, this other question mention that the Haskell platform now uses MinGW rater than Cygwin to run GNU software.
I changed in the cabal configure file the location of gcc, but I still get the same error message (but with the new location of gcc).
So I'm a bit confused here: what is exactly the problem with gcc? Do you have any inputs on how I could continue the building of my software?
Fixed (partially) by using Stack. Building is failing but for another reason, so I'll ask another question.
Thanks again.
I'm learning SDL through Lazy Foo's tutorial, but I can't proceed further as IMG_Load doesn't seem to work. I tried setting it up like he says, but it just doesn't work. I put all the include files into include folder, and all the lib files into the lib folder. What I found is that there were x86 and x64 folders in the lib folder. When I tried x64 (because I have a 64-bit system)it all worked fine, CodeBlocks even told me suggestions (like when I wrote "img" it showed up a suggestion "IMG_Load" (which means the library got initalized?)), but when I come to compiling my code, this happens: http://puu.sh/3Eqa5.png. When I try with the x86 version, exact same error.
I had a little search around the internet, and all I could find were a few threads, but most of them were abandoned. The closest I got to answering my problem was this: http://www.dreamincode.net/forums/topic/118299-sdl-image-error-sdl/ but the guy solved his problem by downloading a problem which Linux can use, not Windows.
}
I'm running Windows 7 64-bit, CodeBlocks 12.11, SDL 1.2.15 and SDL_Image 1.2.12.
I really don't know what the problem is!
You should go to the Compiler and Debugger settings again and under the Linker Settings tab paste:
-lSDL_image
In addition to the #Aleeee's answer, a command line solution is to add -lSDL2_image compiler flag (SDL2 is the up-to-date version by the time of this writing).
Compilation example:
gcc -o object_file_name source_file_name.c `sdl2-config --cflags --libs` -lSDL2_image
It turns out the SDL_Image library I was using was buggy. I don't know how that happened though. I just had to use a older version. Thanks to anyone who helped!
I'm trying to compile the NTL library (host is 64 bit, but target platform is 32), but I'm having some trouble with libtool. The command, alongside with the output can be found in this pastebin. I know I'm doing something wrong with the rpath structure, but I'm not all too familiar with it to know exactly what. Any help?
EDIT: Configure is run as:
./configure CC=/tmp/ntl-build/bin/arm-linux-androideabi-gcc CXX=/tmp/ntl-build/bin/arm-linux-androideabi-g++ SHARED=on AR=/tmp/ntl-build/bin/arm-linux-androideabi-ar RANLIB=/tmp/ntl-build/bin/arm-linux-androideabi-ranlib NTL_GMP_LIP=on GMP_PREFIX=/prod/android-ndk-r8/workspace/verifiable/gmp-precompiled/armeabi-v7a DEF_PREFIX=/tmp/ntl-build/install_dir
How's FFT.o compiled? The huge cascade of error messages that ends with:
.libs/FFT.o: could not read symbols: File in wrong format
indicates that something doesn't match up. From the paste, it seems as if you have cross compiled with the Android NDK tools, but are linking with the native (x86_64) gcc (which in turn calls the native ld).
I have another OSX application problem. I want to bundle in my final application several dylibs, all of them needed by the application and by other dylibs.
I change its references using the install_name_tool, but some of the libraries couldn't be changed properly, having this error:
install_name_tool: changing install names or rpaths can't be redone for: aLibrary.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
So I added the headerpad_max_install_names option flag on the linker flags of the xcode project (Project Properties-Build Settings-Linking-Other Linker Flags). Also I verified in the build log, if the option flag was included, and the option flag was included properly.
But still having the same error in the last dylibs.
Is there any way to bundle all the libraries needed in a unique Framework? Or am I doing something wrong in the building process?
Hope I'm clear with the main problem.
Thanks!
I had this same problem, using C++ and Code::Blocks, and I fixed it by switching from g++ to clang++
Im trying to get gcc running on my Kindle 3. I have a native terminal and ssh working, and I found that the Sourcery G++ toolchain for arm eabi linux produces working binaries, so it seems like I should be able to just configure gcc to build using arm-none-eabi-gcc and compile it, but Im obviously misunderstanding something... When I configure with --target=arm-none-eabi --host=arm-none-eabi and run make, it compiles using gcc, not arm-none-eabi-gcc. Unless theres some pre-compilation phase that uses gcc? I havent gotten all the way through the build yet, since Ive had other errors im working through, but I dont want to waste all this time if im configuring something wrong in the beginning. I found this question, Compile GCC with Code Sourcery where the op seems to want the same thing, but it was never answered... Also, Ive run into problems when compiling lua with the sourcery compiler, it seems to be using a different version of GLIBC, which I assume will be a problem. Is there any easier way to do this?
/pathToStuffifNotPathed/arm-none-linux-gnueabi-g++ foo.c
Should you not invoke the compiler via it's tool-chain invocation? I believe so.