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.
Related
I'm looking for a cross compiler to compile for linux under the msys2 environment.
I'm looking for somethink like x86_64-w64-linux-gcc. But I can't find it.
Which package I have to install?
You'll need a VM or a Linux machine to test the resulting binaries, so I'd just compile on one in the first place.
But cross-compilation should be possible too:
Boot up your favorite Linux distribution in a VM.
Install the libraries you want to have. Install g++ to get libstdc++, and possibly other basic libraries.
Copy the root directory / from the VM to the Windows machine.
You only need headers and libraries, not everything. You'll have to experiment to know what directories can or can't be safely removed.
Install Clang on the Windows machine. Installing LLD is also a good idea (it's a separate package in MSYS2; or, if you're using the official Clang binaries, it's bundled with them).
We're using Clang, because it's inherently a cross-compiler, i.e. doesn't require separate binaries to target a different platform, unlike GCC.
Compile with Clang with --target=x86_64-pc-linux-gnu --sysroot=path/to/root/directory.
-fuse-ld=lld is probably a good idea as well.
The string x86_64-pc-linux-gnu was obtained by running clang++ --version on a Linux machine.
You might need a few more flags, but this should be a good starting point.
My developing/producing environments are all CentOS-7.7.
In order to compile my program with gcc-8.3.0, I have installed "devtoolset-8" on my developing env, but it can not be used in the way same as gcc-4.8.5 that was shipped with CentOS7 oringinally.
Every time I need to compile a program, I must use "scl enable devtoolset-8 -- bash" to switch to gcc8 instead of gcc4.8.5.
When the program was deploying onto the producing-env, there is no gcc8, nor libstdc++.so.6.0.25, so it can not run.
I guess libstdc++.so.6.0.25 should be released with gcc8? I can neither install "devtoolset-8" on the producing-env, nor build gcc8 from source on the producing env.
The version of libstdc++ that can be installed from the official yum repo of CentOS, is libstdc++.so.6.0.19, hence my programs can not be loaded at the producing-env.
How to let such programs to run?
Thanks!
Pls forgive my Ugly English.
In order to not have to copy or ship a separate libstdc++.so but rather link statically (as suggested in a comment) against the C++ runtime, one can link C++ programs with -static-libstdc++ (also specifying -static-libgcc will also make sure that the program does not depend on a recent enough version of libgcc_s.so on the system - although that should rarely be a problem).
There can also be the issue of the target system having a version of glibc that is too old (relative to the build system). In that case, one could anyhow compile gcc of no matter how recent of a version on the older system, so that the resulting C++ executables as well as libstdc++ are linked against the older glibc. Linking C++ programs with -static-libstdc++ will again help to not depend on the program having to be able to find libstdc++.so at run-time.
Finally, the C++ program could also be linked with -static not depending on any dynamic libraries at all.
I'm a student doing research involving extending the TM capabilities of gcc. My goal is to make changes to gcc source, build gcc from the modified source, and, use the new executable the same way I'd use my distro's vanilla gcc.
I built and installed gcc in a different location (not /usr/bin/gcc), specifically because the modified gcc will be unstable, and because our project goal is to compare transactional programs compiled with the two different versions.
Our changes to gcc source impact both /gcc and /libitm. This means we are making a change to libitm.so, one of the shared libraries that get built.
My expectation:
when compiling myprogram.cpp with /usr/bin/g++, the version of libitm.so that will get linked should be the one that came with my distro;
when compiling it with ~/project/install-dir/bin/g++, the version of libitm.so that will get linked should be the one that just got built when I built my modified gcc.
But in reality it seems both native gcc and mine are using the same libitm, /usr/lib/x86_64-linux-gnu/libitm.so.1.
I only have a rough grasp of gcc internals as they apply to our project, but this is my understanding:
Our changes tell one compiler pass to conditionally insert our own "function builtin" instead of one it would normally use, and this is / becomes a "symbol" which needs to link to libitm.
When I use the new gcc to compile my program, that pass detects those conditions and successfully inserts the symbol, but then at runtime my program gives a "relocation error" indicating the symbol is not defined in the file it is searching in: ./test: relocation error: ./test: symbol _ITM_S1RU4, version LIBITM_1.0 not defined in file libitm.so.1 with link time reference
readelf shows me that /usr/lib/x86_64-linux-gnu/libitm.so.1 does not contain our new symbols while ~/project/install-dir/lib64/libitm.so.1 does; if I re-run my program after simply copying the latter libitm over the former (backing it up first, of course), it does not produce the relocation error anymore. But naturally this is not a permanent solution.
So I want the gcc I built to use the shared libs that were built along with it when linking. And I don't want to have to tell it where they are every time - my feeling is that it should know where to look for them since I deliberately built it somewhere else to behave differently.
This sounds like the kind of problem any amateur gcc developer would have when trying to make a dev environment and still be able to use both versions of gcc, but I had difficulty finding similar questions. I am thinking this is a matter of lacking certain config options when I configure gcc before building it. What is the right configuration to do this?
My small understanding of the instructions for building and installing gcc led me to do the following:
cd ~/project/
mkdir objdir
cd objdir
../source-dir/configure --enable-languages=c,c++ --prefix=/home/myusername/project/install-dir
make -j2
make install
I only have those config options because they seemed like the ones closest related to "only building the parts I need" and "not overwriting native gcc", but I could be wrong. After the initial config step I just re-run make -j2 and make install every time I change the code. All these steps do complete without errors, and they produce the ~/project/install-dir/bin/ folder, containing the gcc and g++ which behave as described.
I use ~/project/install-dir/bin/g++ -fgnu-tm -o myprogram myprogram.cpp to compile a transactional program, possibly with other options for programs with threads.
(I am using Xubuntu 16.04.3 (64 bit), within VirtualBox on Windows. The installed /usr/bin/gcc is version 5.4.0. Our source at ~/project/source-dir/ is a modified version of 5.3.0.)
You’re running into build- versus run-time linking differences. When you build with -fgnu-tm, the compiler knows where the library it needs is found, and it tells the linker where to find it; you can see this by adding -v to your g++ command. However when you run the resulting program, the dynamic linker doesn’t know it should look somewhere special for the ITM library, so it uses the default library in /usr/lib/x86_64-linux-gnu.
Things get even more confusing with ITM on Ubuntu because the library is installed system-wide, but the link script is installed in a GCC-private directory. This doesn’t happen with the default GCC build, so your own GCC build doesn’t do this, and you’ll see libitm.so in ~/project/install-dir/lib64.
To fix this at run-time, you need to tell the dynamic linker where to find the right library. You can do this either by setting LD_LIBRARY_PATH (to /home/.../project/install-dir/lib64), or by storing the path in the binary using -Wl,-rpath=/home/.../project/install-dir/lib64 when you build it.
I have Lion 10.7.3 with the Command-line tool installed. I wanted to experiment with C++11, so I used homebrew to install GCC 4.7 as documented here.
How can I now upgrade the /usr/bin/g++ to be the one installed by Homebrew? Is it as simple as symlinking it? I just want to double check and make sure. Thanks!
First, are you sure you need g++ 4.7? As you can see from the C++11 implementation status page, recent versions of clang support most of C++11 too. Of course there are still things that g++ handles and clang doesn't, but there are also still things that clang supports and g++ doesn't. And, more importantly, you already have a recent version of clang, from Apple, configured and ready to go, as your default compiler. Plus, g++ after 4.2 doesn't support Mac extensions like, say, -arch, which means you can't use it to build a whole lot of third-party software (because most configure scripts assume that if you're on a Mac, your compiler supports Mac extensions).
But if you want g++ 4.7, you can do it. Just not by trying to replace /usr/bin/g++ with a different version. Never replace anything in /usr/bin (or /System) with non-Apple stuff except in a few very rare cases (when you have a strong reassurance from someone who knows what they're talking about).
A better thing to do is to just install another compiler in parallel. Just let Homebrew install its favorite way (so it installs into some prefix like /usr/local/Cellar/gcc/4.7, then symlinks all the appropriate stuff into /usr/local/bin, etc.), and use it that way.
When compiling your code, instead of writing g++, write /usr/local/bin/g++, or g++-4.7.
If you get tired of doing that, put /usr/local/bin higher on your PATH that /usr/bin, or create a shell alias, or stick it in the environment variable CXX and write $CXX instead of g++.
If you're using a GUI IDE, you should be able to configure it to use your compiler by setting the path to it somewhere. (Unless you're using Xcode, which you can only configure to work with Apple-tested compilers.)
This is all you need for experimenting with your own code. If you want to compile third-party applications with this compiler, that may be a bit more complicated. You don't often actually compile each source file and link the result together; you just do configure && make and let them do the heavy lifting for you.
Fortunately, most packages will respect the standard environment variables, especially CXX for specifying a default C++ compiler and CC for a default C compiler. (That's why I suggested the name CXX above.)
Just remember that, again, g++ 4.7 doesn't support Mac extensions, so if you're not prepared to debug a bunch of autoconf-based configure scripts complaining that your compiler can't generate code because it assumed it could throw -arch x86_64 at any compiler on a Mac, etc., don't do this.
Is it possible to use the stock (non-apple) version of g++ on Mac OSX 10.7? I want to be able to use the stock g++ without running a virtual linux box on my mac. The reason I want to do this is because apple's version of g++ doesn't warn you when there are unused variables and etc. I'm doing some assessed C++ problems in my numerical methods course and I want to make sure I'm not making any mistakes.
It was suggested I make a symbolic link to a linux version of g++ for compiling the code for the assessments. How do I go about doing that?
Thanks
A linux version of the compiler will not work on what is (essentially) a bsd port.
Are you sure that the current version of g++ cannot warn on the conditions you expect?
Finally, if #2 is true, there is nothing stopping you from getting another version of g++ (compiled for MacOSX) that doesn't have this issue.
A binary for g++ for Linux won't run on MacOSX.
You could compile GCC from its source code; use the latest release i.e. 4.6.2. But that requires some work. Be sure to follow the installation instructions, in particular care about dependencies (like PPL & Cloog) and configure (appropriately) and compile in a build tree outside of the source tree.