I just installed msys2 and mingw64, with their development packages. I really need perl-Gtk3. Perl is msys2 and compiled with gcc-4.9.x, Gtk and friends are mingw and compiled with gcc-5.
Perl complains "Glib.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xdd80080)" when building Glib. Should this work?
Thanks.
PS ... mingw-w64-x86_64-perl is simply unable to compile. And yes, I'm careful to use a mingw shell vs an msys shell.
Are you still having this problem? I have been able to build a Perl dev environment in MinGW64, current as of this time.
I have been able to build Perl Gtk2 / Gtk3 applications in that environment and the GUIs work. (Both Gtk2 and Gtk3 based). These applications are used in a production environment with several thousand desktop users. The application runs on OSX, Windows, and Linux, and can be packed into a binary for release as an "executable" for those operating systems. The details here are for the Windows version.
I do this by either installing the requisite system packages first with pacman, then as necessary rebuilding whatever system library packages that I may have modified, from source, using makepkg-mingw.
Then I build the requisite Perl modules using the CPAN shell, and the "look" command.
I use pkg-config to detect what library and header files are needed.
I then build (at minimum), the Perl Glib, Pango, Cairo, Gtk2, and Gtk3 modules using the perl Makefile.PL command.
The LIBS and INC options need to be added to that command to create a Makefile that includes the correct header files, and links to the correct libraries. The EXTRALIBS and LDLOADLIBS sections of the Makefile needs be correct.
Also ExtUtils::MM_Win32.pm ExtUtils::Liblist::Kid.pm needed to be edited due to the different archname reported by the MinGW64 perl.
I am only giving a general answer, because I was thinking offing a YouTube video on this. If this is a desired topic I will.
Related
I have an embedded project for ARM platform, specifically aarch64.
Up until now I was using Make. I recently set up CMake with no particular issues.
I moved to CMake because I was under the impression it was a more modern build tool that would have allowed a smarter configuration.
For example, I can compile my project using different toolchains (aarch64-elf-gcc-linaro, aarch64-linux-gnu-gcc,...) and I would like CMake to try if any of those are installed on the system and use whichever is found first by default.
Is this possible (or meant to)? I'd expect it to be an easy feat for the tool, but after searching for a while I can't seem to find the right track.
Yes, you can make your CMake project to search for available tool-chains installed in your OS, choose one and compile your project. I also write a CMake program for ARM embedded project, because now it is universal transferable between different OS system Windows and Unix. On Linux there is ARM ToolChain installed and on Windows there is Keil-MDK. If you have different tool-chains to choose between, you can write CMake script which will find paths with command like find_path() and then call correct "toolchianxx.cmake" script with right compiler flags for chosen compiler.
In your particular problem just use find_path commands and use hits to find installed compilers in "pre-set" known paths.
I'm using external cmake with msys2, since cmake-gui provided by msys2 won't run (invalid win32 application). Now the problem is there's only so much I can configure using cmake-gui. I downloaded OpenALSoft today and when I ran make install it installed to C:\Program Files (x86)\. How do I configure external cmake to install into mingw32 or mingw64 depending on what's running? On top of that, I'm having a problem differentiating between PATH RPATH and PREFIX (and how those correspond to msys2 install structure), so if you could, please, clarify those too, I'd really appreciate that.
I always use this invocation to make sure the install directory is set to /mingw32 or /mingw64:
MSYS2_ARG_CONV_EXCL=- cmake . -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
And then when you want to install the built project, you must do this:
make install DESTDIR=/
All of this trickiness is due to the fact that CMake is a native Windows program that does not understand MSYS2-style paths like /, and MSYS2 has some automatic conversions of paths that happen when it detects you are running a native Windows program like CMake.
By the way, MSYS2's cmake-gui works for me, so maybe you should try reinstalling the CMake package in MSYS2 or something. However, I expect my answer to work for both the external CMake and the one in MSYS2.
I'm a maintainer of a program that I'd might like to propose for inclusion in the Cygwin distribution.
We use CMake so there is a packager available, and it's easy to create a .bz2 package.
Once I've created the package, how can I try it locally? In Linux this can easily be done, but is there a way to use the Cygwin package installer so that it picks up a local package?
I've read the package contribution documentation and related pages but can't find an answer.
The CMake Cygwin package generator seems extremely out-of-date. Cygwin hasn't used .bz2 for some years. This is from a Cygwin-mailing list answer from Adam Dinwoodie:
Cygwin packages generally use Cygport to define the build process and
so forth. It's more-or-less the equivalent of rpmbuild for RPM
packages, and similar tools for other distribution systems. The
documentation for Cygport is at http://cygwinports.github.io/cygport/;
if you're using make in a reasonably standard way, most things should
Just Workâ˘.
In particular, if you're using Cygport, it'll automatically do things
like creating setup.hint files for you.
For testing locally, I find it's simplest to just do tar -xaC/ -f
<tarball> on the compiled tarballs that Cygport generates. That
doesn't test the dependency management or anything that requires
post-install scripts, but it's fine for checking the installation
itself works.
I want to use KDL (Kinematics and Dynamics Library) in robot control box. But robot control box uses SCons as their build system while KDL uses CMake.
It turned out that the control box doesn't have CMake installed. Should I install CMake in the control box? Or write SCons file for compiling KDL?
====================================================
My question is ambiguous. Sorry for that. And unfortunately, I cannot show the link of Control Box, it's not public. Here is link of KDL installation manual.
http://www.orocos.org/kdl/installation-manual
Let me make it more clear.
Forget all of previous question above and all about Control box, KDL. Let's say that you want to use one library. But the library can be built using CMake according to installation manual. Your PC doesn't have CMake installed but it has SCons, and unfortunately you should not install CMake on your PC.
If you can only use SCons, what can you do?
I know this situation is not usual, I want to know your opinion.
To answer your initial question: Yes, you should always try to install CMake, if that is a build requirement for you library and if you need to build that library from the sources.
To answer your later question: Replacing or rewriting the build system scripts is a major effort and not advisable. In general there is no script to convert build-systems. Such script might help to make the manual transformation. If you have a look at LLVM's effort to replace Autotools by CMake or Boost replacing it's own build system by CMake, you find out it takes several people several years and still not everybody is satisfied.
Often you don't need to build the library yourself. Either there are already built packages from the project directly of from your distribution (Debian etc. packages) or third party packagers like Mac Ports or NuGet.
In your case KDL provides Debian/Ubuntu packages.
Additional KDL is part of ROS, which is experimental in Homebrew for OS X.
Can cmake configuration files also be used to automatically extend the system PATH variable to include the directory paths to all the installed executable applications and if it is possible (and a standard practice), how can I do this?
This way, as soon as I configure all the CMakeLists.txt files and everything compiles (and hopefully runs) nicely, I can start using the applications, and the path configuration would be packaged together with the build process. I am working with Linux and my code is written in C++, but since cmake is cross-platform, the question extends to other systems as well.
I'm unaware of any capability in CMake to do this. However, we based what we do what Cantera does. They upgraded to SCONS recently instead of their old build system, but the idea still applies.
Anyway, there's a script that CMake configures with the paths during the configure step and then installs somewhere. So once built on Linux, one would run make install then source ~/setup_cantera and it sets up all the variables needed.
We do the same thing for our libraries built with CMake. It's possible to detect which shell the user is running and configure an appropriate template script.