I am new to Linux environment, we have task to migrate a Windows wxWidgets(version 2.4.2) GUI application to Linux platform(RHEL8 or 8.3).The application is successful on Visual studio 2017&2019(Compiler MSVC++ 14.1 and 14.2) using the wxWindows-2.4.2(very old one). But when i try to build wxWindows2.4.2 on Linux( g++ (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5))
../configure --with-gtk=2
at configuration stage process stopped saying
checking for toolkit... configure: error: Please specify at most one
toolkit (maybe some are cached in configarg.cache?)
I tried by installing "Development Tool" on Linux but getting same thing.
Source: https://github.com/wxWidgets/wxWidgets/archive/refs/tags/v2.4.2.zip
You can successfully run the configure phase by first performing dnf install gtk2-devel, and then configuring with ./configure --enable-gtk2.
However, (not surprisingly), wx 2.4.2 will not successfully build on RHEL8 (I tried); there will be a bunch of compilation errors. Those are not impossible to fix, but I wonder if that's worth the trouble – there probably would be runtime errors and/or misbehaving GUI components at the next stage.
While I understand your strategy of choosing the old wx version that the application is known to work with on Windows, it seems to be the hard way in this case.
How to run g++-6 on debian 10, need to compile older buildroot files.(NCurves(host-ncurses-5.9) is crashing)
I have tried to patch the files in the buildroot but it like walking into a swamp.
Fixing one problem to find the next problem.
Tried compiling 6.3 compiler from source but this is crashing with the latest gcc-8 compiler.
Any suggestions? (I always assumed that older compilers should compile with newer compilers)
My other options are:
* Running virtual machine (VM or docker) with Debian Jessie
* Compile an older compiler with a docker GCC compiler.(No idea if this works)
* maybe turn off the compiling of the local files in buildroot? (Could not find any info on this)
There is a gcc-6 package available in Debian. So you just need to sudo apt install gcc-6. link
No reason to compile gcc from source unless you need a very specific version, but even then Docker is the far easier solution since gcc has an official repo on Docker Hub. I'd also double check that you have the proper ncurses dev library installed.
The overall best solution is to containerize the correct build environment (compiler, libraries, etc.), though. It ensures you'll always be able to build the product, especially if a re-factor is not viable.
https://bitbucket.org/alfonse/gltut/downloads
this is the repository for the several tutorials in this online-book
http://www.arcsynthesis.org/gltut
the author uses premake as alternative to cmake, and i have tried every possible command line options but nothing works.
I don't get why the author wants to use the latest tool on earth but i need to solve this and i don't even have a clue about Lua and this tool.
For who wants to help me with this you have to download this to actually build the demos and put it in the root folder of your gltut project.
The URL for the mercurial repository is
hg clone https://bitbucket.org/alfonse/gltut
My OS is Ubuntu 12.04 64 bit.
I just noticed that the premake version that comes with Ubuntu 12.04 is the 3.7, just download a newer version from the 4.x branch and the problem is solved.
I'm used to manually install GCC from source before on Ubuntu and it was a painful process. So I really don't want to do repeat this process. Currently, I have MinGW and GCC (4.6.2) installed on my machine. So is there an easy way to update GCC without building it entirely from source? Has anyone done it before can share me some tips?
Update using terminal:
Run the command prompt/terminal (cmd or sh).
Update the package list:
mingw-get update
After updating the package list, run:
mingw-get upgrade
When the command finishes running, all of your packages will be upgraded.
Update using the GUI version:
If you aren't used to the terminal, there is also a GUI version of MinGW called "MinGW Installation Manager", which is normally located at:
C:\MinGW\libexec\mingw-get\guimain.exe
When the GUI is open, tap Installation -> Update Catalogue. This will update the package list.
After that, tap Installation -> Mark All Upgrades. This will select all of the packages which can be upgraded.
Finally, tap Installation -> Apply Changes to apply the upgrades.
Snapshots and release builds of the MinGW http://code.google.com/p/mingw-builds/downloads/list
UPDATE: As of Nov-5-2012, MinGW includes 4.7.2 of the GCC compiler, which is the most current version. I personally will use the MinGW package, since it includes MSYS and other tools, and since it is the defacto standard, I hope that it is better supported. The only drawback is the included GDB does not include Python scripting, but I think that can be updated separately.
I don't know if you can update the GCC in MinGW, but there are alternative projects to MinGW with newer versions of GCC.
The MinGW-builds project provides a package similar to MinGW but with an updated GCC (4.7.2). I extracted the files to c:\MinGW (so I could use the same path) after moving my existing MinGW to another folder. Only MinGW has MSYS, so if you need that (I did) copy the msys folder from the original MinGW.
After installing MinGW-builds, the result of g++ --version:
g++ (Built by MinGW-builds project) 4.7.2
The latest GCC that comes with standard MinGW is currently 4.7.0. I compiled a few simple projects in Code::Blocks, and the latest wxWidgets source, and everything seems to work.
It's worth noting that MinGW-builds includes a Python script enabled version of GDB, in case you want STL pretty printer support, or other GDB Python features.
Another good choice is TDM-GCC, which is a project that hosts an impressive installer that includes an updated GCC compiler (4.7.1) and support tools. It is a standalone package. As far as I can tell, Python scripting is not supported in the GDB that comes with this package.
Finally there is the MinGW-w64 project, which is a fork of MinGW. Rubenvb, who posted an answer to this question, has good standalone packages (in the personal builds folder) based on this project which include an updated GCC (4.7.2). The included GDB seems to be Python script enabled.
if you use MSYS2
just open mingw64-console and type in:
# Update the package database and core system packages with:
pacman -Syu
# If needed, close MSYS2, run it again from Start menu. Update the rest with:
pacman -Su
I have built a more up to date GCC 4.7 (it's built within code freeze, so it should be equivalent with the release). Also, this build contains <thread> support.
32-bit
64-bit
The -gcc_linux package is what you want if you want to use it on Linux. Just extract somewhere and add the mingw??/bin directory to PATH.
PS: There's a native Windows compiler and a Windows Clang build. I suggest using Clang only with one of my GCC 4.6 builds, as it has trouble with GCC 4.7's libstd++. Extract the Clang package in the same directory as the GCC package and it will work out of the box.
The MinGW-w64 build from http://winlibs.com/ has the latest GCC version and requires no installation, just unzip the download. To upgrade you can just replace the mingw32 or mingw64 folder with the new version.
To get latest MinGW64 in Windows: https://sourceforge.net/projects/mingw-w64/?source=typ_redirect
For all platforms: https://mingw-w64.org/doku.php/download
You just need to update your g++ compiler if its not.
First problem can be solved through this:
Update using the GUI version:
If you aren't used to the terminal, there is also a GUI version of MinGW called "MinGW Installation Manager", which is normally located at:
C:\MinGW\libexec\mingw-get\guimain.exe
When the GUI is open, tap
Installation -> Update Catalogue
. This will update the package list.
After that, tap
Installation -> Mark All Upgrades
. This will select all of the packages which can be upgraded.
Finally, tap
Installation -> Apply Changes
to apply the upgrades.
2nd Problem could be that if you didn't updated the path of mingw in environment variables.
I am trying to deploy my application from development environment to users' computer, but I have some issues.
First, I compile and run it on my development computer (higher version Ubuntu11.04):
Ubuntu11.04$ make
Ubuntu11.04$ ./MyApp
Program runs okay.
Then I copied the binaries MyApp to two lower-version machines (users' computer):
Ubuntu10.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
Ubuntu8.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./MyApp)
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
However, if I compile the source code on Ubuntu10.04, and run it:
Ubuntu10.04$ make
Ubuntu10.04$ ./MyApp
Program runs okay.
What should I do with this? When I compile it in development environment, how can I set the version number of the used library? I'm not directly using GLIBCXX, I think it's being used implicitly somewhere in my project.
Thx a million.
Peter
Did you see Link with an older version of libstdc++
I have never installed an older version of g++, but I have included a libstdc++.so in my release and that has worked for me. Best solution I have seen is get your development stuff to work on the oldest possible system. We compile some stuff on Red Hat 9 and it work on everything, but it can be any major issue building on old machines as you say.
You have built on version N, and tried to deploy on version M, M<N. You will need to get the deployment computer upgraded, or learn the procedure to compile and link targeting an older version. Since the problem lives in libstdc++, I'm afraid that my advice is to downgrade your entire dev system or upgrade the target, libstdc++ is not easy to deal with. Another answer here has someone's recipe.
Keep in mind that the Ubuntu/Debian community is optimized for open source. From their point of view, the solution to this is for you to distribute source code with the auto* tools, and let the user built it for him or her-self. They don't stay up late making this easy for you.
Here in the evil world of closed source, we keep around VMs running all sorts of old linux distros just so that we can build a single binary that runs in many places.