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.
Related
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.
I'm trying to compile CMake using a non-default GCC installed in /usr/local/gcc530, on Solaris 2.11.
I have LD_LIBRARY_PATH=/usr/local/gcc530/lib/sparcv9
Bootstrap proceeds fine, bootstrapped cmake successfully compiles various object files, but when it tries to link the real cmake (and other executables), I get pages of "undefined reference" errors to various standard library functions, because, as running the link command manually with -Wl,-verbose shows, the linker links with /usr/lib/64/libstdc++.so of the system default, much older GCC.
This is because apparently CMake tries to find curses/ncurses libraries (even if I tell it BUILD_CursesDialog:BOOL=OFF), finds them in /usr/lib/64, and adds -L/usr/lib/64 to build/Source/CMakeFiles/cmake.dir/link.txt, which causes the linker to use libstdc++.so from there, and not my actual GCC's own.
I found a workaround: I can get the path to proper libraries from $CC -m64 -print-file-name=libstdc++.so then put it with -L into LDFLAGS when running ./configure, and all works well then.
Is there a less hacky way? It's really weird that I can't tell GCC to prioritize its own libraries.
Also, is there some way to have CMake explain where different parts of a resulting command line came from?
I have a project written in gcc - bison -flex on Linux environment. All the project is implemented into a *.so file and is called from python-tkinter graphic surface.
There is a need to run it on windows. However I'd avoid to install all the windows equivalent of gcc - bison -flex programs.
Is it possible to force gcc IN LINUX ENVIRONMENT to compile WINDOWS DLL instead of *.so? It could make life easier to use the same technics as I do now: just do calls from python-tkinter graphic surface.
You can, of course, cross-compile it.
You'll need some packages installed, though.
Your normal project would be able to build if you use the MINGW equivalent of GCC for the target architecture.
Also, take a look at this:
Manual for cross-compiling a C++ application from Linux to Windows?
The linking can be kind of troublesome though, since it could come a time where softlinking fails due to versions. In that case you'll need to create some symbolic links to the correct version.
The output of the compilation process should be with -o DYNAMIC-LIBRARIE-NAME.dll and of course use the -shared flag.
Hope it gives you some pointers..
Regards.
I would like to build some code in new C++11. Our machine allows only g++4.4.7 that is old for that. We have available also clang++ 3.4 that as far as I understood supports the new features.
While I am doing first tests with clang++ it looks like it does requires c++ header files from g++. Having available version g++4.4 this will prevent my code to use the new C++11.
Is it really so? Is there a way where I can use clang++3.4 to build C++11 code without having latest versions of g++ ?
Try libc++, on linux should work just fine
http://libcxx.llvm.org/
I'm trying to build gcc 4.7.2 under MinGw with cc,c++,fortran,objc and java.
When it reaches to the compiling libgcc at final linking level it gives an error.
cannot find dllcrt2.o
Followed by
cannot find -lmingwthrd,-lmingw32,-lmingwex,-lmoldname,-lmsvcrt,-ladvapi,-lshell32,-luser32,-lkernal32
I think this is because ld.exe couldn't locate /mingw/lib dir.Is there any solution to fix this?I tried googling but nothing worked.
What is wrong with the MinGw compilers they ship that you are trying to build your own set?
Configuring/building GCC is a complex task (even more so in such a hostile environment), a small slip up can lead to results like the ones you see. Recheck each step.
Grab a copy of the source for MinGw and study how they do it, check their documentation.