search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.25k stars 1.21k forks source link

Information: recent omniORB CMake port working well for MinGW64 #7334

Open asctime opened 3 years ago

asctime commented 3 years ago

Hi. For anyone needing OmniORB/CORBA/etc under MinGW64 have a look at the recent CMake port by Julian Scholle: https://github.com/CaeruleusAqua/omniORB-cmake

Seems working OOTB, only minor tweaks needed.

lazka commented 3 years ago

Just wondering, who/what is still using CORBA?

revelator commented 3 years ago

Hmm firebird2 is kind of corba (based on the old borland database), Orbit-2 is also still used on linux for exchange mail clients. Actually i managed to build a working version of Orbit-2 and bonobo but the build steps are kind of akward as mingw Orbit-2 relies on having a working Orbit-2 as a bootstrapper in Msys2. So we could have a windows port of later versions of the evolution mail client again shortly.

asctime commented 3 years ago

AFAIK It's still a build requirement for Salome platform: https://www.salome-platform.org/

In any case, there are hundreds of legacy CORBA apps, so having a recent ORB compatible that's (still) easy enough to build and available probably isn't a bad idea. But anyone who knows the OmniORB source package knows it is an outdated, archaic mess to deal with their ideas of manually modified Makefiles - not to mention the resulting binaries sometimes don't work for MinGW64 anyway. Since someone took the time to update the build system and I tested it working under MinGW64 I thought this information might save someone else the stress.

revelator commented 3 years ago

Personally newer had much luck compiling omniorb but if you can then id suggest making a PKGBUILD with the right flags patches etc. :)

asctime commented 3 years ago

Exactly what I said :) I thought about doing a PKGBUILD that but there are a couple of issues. First I am not the actual maintainer and I am not sure that person even works on it anymore. Second is that I use github very rarely myself. My advice for anyone who would have use for OmniORB simply clone and build hist project directly -> it actually does work and the binaries are the most reliable that I have had for MinGW64. My own intentions don't really go much further than that. I wish I had time to be more active with this project.

revelator commented 3 years ago

hmm well my first try ended miserably and there does not seem to be much info on anything specific that needs to be set on his page. Ill see if i can dig anything further up on it but if you know the build setup it might be better to post it here so i dont have to jump through hoofs to get it running.

asctime commented 3 years ago

I used cmake-gui, being sure to build in a subdir. I am attaching my CMakeCache

CMakeCache.txt

Edit: It's worth pointing out that I did leave some feedback to the original porter: https://github.com/CaeruleusAqua/omniORB-cmake/issues/2

(Most important is to properly adjust codegen.cmake per my comments) I was able to get it working and it makes me happy someone else sees value in that. I'll hang around and support you best I can for what that's worth..

revelator commented 3 years ago

Hmm i used python3 since python2 is deprecated but else pretty much the same, though i did build in bash with mingw64 cmake so the path mangling might act up there ?, atleast im having no joy getting it to compile that way which might indicate a problem as that would rule out PKGBUILD since that relies on bash. Ill try with the override to the msys2 path mangling and see what happens.

asctime commented 3 years ago

Where is the build breaking? Maybe I can assist..

Also yeah, myy experience with mingw64 cmake is the build tend to go smoother from a simple command prompt. As they should, IMHO.

revelator commented 3 years ago

/bin/sh: C:/Msys64/src/64/bin: Is a directory make[2]: *** [CMakeFiles/RunGenerator.dir/build.make:129: generated/lib/omniORB/omniORB4/Naming.hh] Error 126 make[1]: *** [CMakeFiles/Makefile2:698: CMakeFiles/RunGenerator.dir/all] Error 2 make: *** [Makefile:149: all] Error 2

revelator commented 3 years ago

Normally that would also be cool but if you want it added as a package we need to find a solution so that it will work with pacman :)

asctime commented 3 years ago

Agreed, something appears wrong in the environment for sure. Somewhere your 'bin' folder C:/Msys64/src/64/bin is being summoned as something else ("!! Is a directory")

With a customer I'd already be logged into their system lol, but we need to document this anyway.

Can you post your cmakecache and CMakeFiles\RunGenerator.dir\build.make for starts?

revelator commented 3 years ago

Np ;)

revelator commented 3 years ago

Ill zip em up for you tomorrow, and yeah seems like the generator does not like msys2's path mangling i suspect it should have run the just built omniidl.exe to generate the interface header. This is btw why it is somewhat akward to build Orbit2-idl also as it needs an Msys2 version of the idl compiler to get around the path mangling in the mingw* builds. I found that out from the cygwin version so there does not seem to be any easy solution.

asctime commented 3 years ago

Sure. And yeah that would explain it. It's easy to get jaded by the rubbish Windows-makefile packaging used by the upstream OmniORB sourcecode. Throw that book out and just start fresh. The way I have things set up is almost default with just one tweak:

That's about it. You have my cmakecache and the MinGW built omniidl completeed the rest of the build just fine -> no need for an MSYS version AFAICS

revelator commented 3 years ago

Yep this also plagued the older Msys as paths just ended in nothing if the code couldnt handle the windows path conversion. Could probably use your trick to make a PKGBUILD though it would look somewhat odd to the uninformed :)

revelator commented 3 years ago

Or maybe use shell escaping ? hmm.

asctime commented 3 years ago

this also plagued the older Msys as paths just ended in nothing if the code couldnt handle the windows path conversion

But it's worse in MSYS2 for two reasons:

It annoyed me for a while until I finally gave up and put in the symbolic link, never looked back since. BTW I wrote that wrong having MSYS on the brain too much, for correctness:

D:\MSYS2>dir /a
...
01/10/2020  07:37 PM    <SYMLINKD>     MSYS2 [\MSYS2]
...

IMHO shell escaping is always a dogs breakfast, I only need to escape the quotes in one of the cmake file that was it.

revelator commented 3 years ago

Hehe i know the feeling :) been bashing my head in sometimes trying to workaround these cases. Atleast we have a working solution though When i used the old Msys it was /Msys/mingw though you could do it the other way around to.

asctime commented 3 years ago

When i used the old Msys it was /Msys/mingw though you could do it the other way around to.

Really? I'm not sure. I just went with whatever the packaging system did, at that time it was mingw-get. All of the msys stuff went into /MinGW/msys/1.0 or something like that. Later mingw32 adopted msys2 and put that in a subdir as well. I didn't try to change much because it would raise additional issues when asking for support.

"bash-ing my head" lol thats a good one.

Let me know how you go.

revelator commented 3 years ago

Was way back just about when the old Msys project started using mingw-get, i even did some work for them back then trying to port the newer cygwin into a new Msys2 (not related to this one) with some success though at the time i was not yet very good with this build system so it newer really took off. I did notice some packagers used the /mingw/msys layout later though.

Atm. im getting ready for some of my friends who are comming to dinner but i might have an idea for a PKGBUILD script ;)