AdaCore/gtkada

fails to build in msys2

Closed this issue · 34 comments

Trying to build gtk fails with a lot of references to missing GNAT stuff

$ gcc --version
gcc.exe (Rev3, Built by MSYS2 project) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gprbuild --version
GPRBUILD Community 2019 (20190517) (x86_64-pc-mingw32)
Copyright (C) 2004-2019, AdaCore
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I started off with just

./configure --prefix=/mingw64 --build=x86_64-windows

Saw a previous issue and changed that to:

./configure --prefix=/mingw64 --build=x86_64-windows --with-GL=no

It changed the errors to be GNAT based.

I then tried

/configure --prefix=/mingw64 --build=x86_64-pc-mingw32 --with-GL=no

but got the same errors as the previous step. I did a clean inbetween each attempt.

attaching a log file (I didn't log the cleans...forgot to tee those)
makegtk.log

The top of the log file shows my pacman output for all the required dependencies (look for the lines with "[installed]" in them)

This build environment has worked for everything else Ada related except for Adacore repos, so I am guessing there is a dependency not listed in INSTALL?

I built with master cloned today.

I don't think anyone has tested building on msys2 before. __gnat_rcheck_CE_Access_Check is supposed to be included in the libgnat DLL - could you use objdump/nm to see if libgnat.dll provides this under msys2?

Looks like it is there

22:30:08 MINGW64 /mingw64/lib/gcc/x86_64-w64-mingw32/9.1.0/adalib
$ nm libgnat.a | grep '__gnat_rcheck_CE_Access_Check'
0000000000001f46 T __gnat_rcheck_CE_Access_Check
0000000000002234 T __gnat_rcheck_CE_Access_Check_ext
                 U __gnat_rcheck_CE_Access_Check

Does this mean that gtkada is not buildable on msys2 for windows 10?

From https://github.com/msys2/msys2/wiki/MSYS2-introduction:

Beware that mixing in programs from other MSYS2 installations, Cygwin installations, compiler toolchains or even various other programs is not supported and will probably break things in unexpected ways. Do not have these things in PATH when running MSYS2 unless you know what you're doing.

Which likely means that you really shouldn't be mixing in GNAT Community binaries. Instead, I would be tempted to bootstrap gprbuild and then build xmlada and gprbuild before trying to build gtkada. I'd also be tempted to build from 19.2 source instead of master. Not sure how far you could get as I haven't tried it myself.

Interesting, I've been using the community/gpl gprbuild for years with no issue outside of this project. All other Ada libraries build pretty easily with it. I'll work on building it manually and see how that goes.

My first guess doesn't appear to be the root of the problem here. I manually built and installed gprbuild-bootstrap. But then building xmlada fails similarly to what you originally reported, so this doesn't appear to be related to just gtkada. I'm going to work on the problem with building xmlada first and as it is much simpler than all the dependencies with gtkada. I've never used MSYS2 before so it's a bit slow going.

Edit - On a clean system I can't even build xmlada. It fails building libraries complaining of undefined references including __gnat_rcheck_CE_Access_Check.

Build Libraries
   [gprlib]       xmlada_unicode.lexch
   [link library] libxmlada_unicode.dll
c:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Steve\gnat-builder\xmlada-build\unicode\obj\relocatable\unicode-ccs-iso_8859_1.o:unicode-ccs-iso_8859_1.adb:(.text+0x59): undefined reference to `system__img_uns__set_image_unsigned'

I don't believe that @jeremiahbreeden answered @setton's question correctly. On a clean current MSYS2 install with the mingw-w64-x86_64-toolchain, the DLL does not contain __gnat_rcheck_CE_Access_Check, even though the adalib libraries do.

Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64
$ find . -name "libgnat*"
./bin/libgnat-9.dll
./lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat-9.dll.a
./lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat.a
./lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat_pic.a

Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64
Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64/bin
$ nm libgnat-9.dll | grep '__gnat_rcheck_CE_Access_Check'

Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64/bin
Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib
$ nm libgnat.a | grep '__gnat_rcheck_CE_Access_Check'
0000000000001f46 T __gnat_rcheck_CE_Access_Check
0000000000002234 T __gnat_rcheck_CE_Access_Check_ext
                 U __gnat_rcheck_CE_Access_Check

Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib
$ nm libgnat_pic.a | grep '__gnat_rcheck_CE_Access_Check'
0000000000001f46 T __gnat_rcheck_CE_Access_Check
0000000000002234 T __gnat_rcheck_CE_Access_Check_ext
                 U __gnat_rcheck_CE_Access_Check

Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib
$ nm libgnat-9.dll.a | grep '__gnat_rcheck_CE_Access_Check'
0000000000000000 T __gnat_rcheck_CE_Access_Check_ext
0000000000000000 I __imp___gnat_rcheck_CE_Access_Check_ext
0000000000000000 T __gnat_rcheck_CE_Access_Check
0000000000000000 I __imp___gnat_rcheck_CE_Access_Check

Steve@DESKTOP-NEGQGC8 MINGW64 /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib

@steve-cs

So both xml ada and gtkada appear to be failing when building as shared/relocateable. If I disable shared for both of them, I can build both statically. I was able to build xmlada, gprbuild, and gtkada

I don't know if building them only as static is a problem or not yet, but I at least got them to build.

Will not having a shared/relocatable version of gtkada or xmlada be an issue?

Side note: the results of the gtkada build process appear to be the same (unless I missed something) if I am using the community version of gprbuild in the path or if I am using the one I manually built, so using the community gprbuild doesn't appear to be detrimental (at least relative to this problem).

I don't believe that @jeremiahbreeden answered @setton's question correctly. On a clean current MSYS2 install with the mingw-w64-x86_64-toolchain, the DLL does not contain __gnat_rcheck_CE_Access_Check, even though the adalib libraries do.

I tried my best! Not a lot of easy to parse documentation on this stuff for someone unfamiliar, and I generally don't work in linux like environments (or as close as mingw64 is).

Either way, sorry about that then!

Current MSYS2 status appears to be ada support has been removed in the native gcc package, broken with respect to shared library support in the mingw-w64-x86_64-gcc-ada package, and presumably broken in the same way in the mingw-w64-i686-gcc-ada package. If I try to use just the CE toolchain, configure does some strange things leading to failures.

The heavy handed work around is to install mingw-w64-x86_64-toolchain and mingw-w64-x86_64-gtk3 and then put the GNAT CE toolchain in the front of mingw64/bin in the PATH, e.g. export PATH=/c/GNAT/2019/bin:$PATH. At that point building gtkada builds all libraries without complaint.

I noticed that Arnaud Charlet did the heavy lifting to keep Ada from being removed entirely from MSYS2.

msys2/MINGW-packages#4125

Ada is still in the current MSYS2. I checked at work today. You have to use a separate call to pacman to add it in addition to the pacman call to add gcc, but it's in the package manager. You're right that it does appear to be broken in terms of shared libraries though. That may be why I never run into problems with it outside some of the Adacore repos. I think everything else I have worked with has use static libraries.

Yes. Ada is in but broken with regard to shared libraries in the mingw toolchains/repos. Ada is not enabled in the msys toolchains/repos (i.e. /usr/bin/gcc).

I was able to build under MSYS2 by doing

    mv /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat-9.dll.a /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat-9.dll.a.OUT
    cp /mingw64/bin/libgnat-9.dll /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/

(this is for the 64 bit world, of course)

@jeremiahbreeden could you try this on your end?

Edit: after a further look through MSYS2 packages, I'm not at all sure what is normal or desired here. The current state of affairs (use of *.dll.a and location(s) of *.dll) seems to vary by package under MSYS2 and so having libgnat*.dll in /bin and libgnat*.dll.a in /lib might be both intentional and normal. My use of "Bad" and "errant" previously is likely uninformed.

I found the code that removed libnat-9.dll from adalib/. Bad patch in PKGBUILD for mingw-w64-gcc. Haven't found the source of the errant libgnat-9.dll.a.

  make -j1 DESTDIR=${srcdir} install
  if [ "$_enable_ada" == "yes" ]; then
    mv ${srcdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/adalib/*.dll ${srcdir}${MINGW_PREFIX}/bin/
  fi

Introduced in the following commit:

msys2/MINGW-packages@0c60660

(Hmm, looks like the issue predated that commit, but was just placed under an "if" there... right?)

That's certainly how it looks to me.

I was able to build under MSYS2 by doing

    mv /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat-9.dll.a /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/libgnat-9.dll.a.OUT
    cp /mingw64/bin/libgnat-9.dll /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/adalib/

(this is for the 64 bit world, of course)

@jeremiahbreeden could you try this on your end?

This does make it build for shared. Thank you!

A lot of this is above my head as I am not familiar with how the intricacies of GCC and GNAT work, but I wanted to ask: How does moving libgnat-9.dll, which didn't have a reference to __gnat_rcheck_CE_Access_Check in it into adalib make it work? I would have very naively assumed I would have needed to have a .dll with a reference to __gnat_rcheck_CE_Access_Check in the /bin directory instead (the reverse of what was done). Obviously, it works, but was curious why (if it isn't too off topic).

the linker will look for libgnat-9.dll under adalib, not under bin, this is why the DLL absolutely needs to be there. libgnat-9.dll.a is supposed to remove this need, but clearly this isn't working here. And the __gnat_rcheck and other runtime symbols are definitely there in libgnat-9.dll.

Should I close this issue or do yall want to keep it active?

Closing this, I think the issue should be followed up on the msys2 world. Thanks again @jeremiahbreeden for reporting this!

I should have gotten to this sooner ...

It turns out that all that is needed to get Ada shared libraries working (tested building gprbuild-bootstrap, xmlada, gprbuild, gtkada) is to remove the three places where the gcc PKGBUILD was patched trying to fix it in the first place. Things are back where Arnaud said they should/must be. My proposed patch is deleting 6 lines. Within MSYS2, this should be applied to both the gcc and gcc-git PKGBUILD files.

Administrator@WIN-0UPEFM8L0AS MINGW64 ~/MINGW-packages
# git diff
diff --git a/mingw-w64-gcc/PKGBUILD b/mingw-w64-gcc/PKGBUILD
index 476ac2f18..01f58ff10 100644
--- a/mingw-w64-gcc/PKGBUILD
+++ b/mingw-w64-gcc/PKGBUILD
@@ -113,7 +113,6 @@ prepare() {
     0008-Prettify-linking-no-undefined.patch \
     0009-gcc-make-xmmintrin-header-cplusplus-compatible-depre.patch \
     0010-Fix-using-large-PCH.patch \
-    0011-Enable-shared-gnat-implib.patch \
     0012-Handle-spaces-in-path-for-default-manifest.patch \
     0014-gcc-9-branch-clone_function_name_1-Retain-any-stdcall-suffix.patch

@@ -219,9 +218,6 @@ build() {
   rm -rf ${srcdir}${MINGW_PREFIX}

   make -j1 DESTDIR=${srcdir} install
-  if [ "$_enable_ada" == "yes" ]; then
-    mv ${srcdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/adalib/*.dll ${srcdir}${MINGW_PREFIX}/bin/
-  fi
 }

 package_mingw-w64-gcc-libs() {
@@ -404,8 +400,6 @@ package_mingw-w64-gcc-ada() {
   cd ${srcdir}${MINGW_PREFIX}
   cp bin/gnat*.exe ${pkgdir}${MINGW_PREFIX}/bin/

-  cp bin/{libgnarl*,libgnat*}.dll                       ${pkgdir}${MINGW_PREFIX}/bin/
-
   mkdir -p ${pkgdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}
   cp -r lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/adainclude     ${pkgdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/
   cp -r lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/adalib         ${pkgdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/

My recommendation would be to replace the second hunk (mv part) by a cp, since having the DLLs in the bin directory is much friendly for executing (as opposed to linking).

In other words, you need the DLL to be found under adalib for linking, and under bin for executing:

Something like (untested):

if [ "$_enable_ada" == "yes" ]; then
cp -p ${srcdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+}/adalib/.dll ${srcdir}${MINGW_PREFIX}/bin/
fi

and this also means you do want to keep the third hunk:
cp bin/{libgnarl*,libgnat*}.dll ${pkgdir}${MINGW_PREFIX}/bin/

since gnat*.exe is also copied under ${pkgdir}${MINGW_PREFIX}/bin/, so *.dll should as well.

This means getting rid of 0011-Enable-shared-gnat-implib.patch which is probably what we want although I haven't looked at what 0011-Enable-shared-gnat-implib.patch contains.

@steve-cs @ArnaudCharlet

I can try opening up an issue on the msys2 repo and see where it goes. I'm not experienced at all at creating and modifying packages for package managers, so I am not really sure what I would propose. Would it be better to have someone who knows what is going on fully and what the changes need to be open the issue or should I just open an issue an point them to here?

@ArnaudCharlet - That makes perfect sense. Tested and working including gtkada make tests and running testgtk.

@jeremiahbreeden - in a more perfect world someone from the MSYS2 Ada community would pick this up.

Simpler/better two line fix:

# git diff
diff --git a/mingw-w64-gcc/PKGBUILD b/mingw-w64-gcc/PKGBUILD
index 476ac2f18..84721f712 100644
--- a/mingw-w64-gcc/PKGBUILD
+++ b/mingw-w64-gcc/PKGBUILD
@@ -113,7 +113,6 @@ prepare() {
     0008-Prettify-linking-no-undefined.patch \
     0009-gcc-make-xmmintrin-header-cplusplus-compatible-depre.patch \
     0010-Fix-using-large-PCH.patch \
-    0011-Enable-shared-gnat-implib.patch \
     0012-Handle-spaces-in-path-for-default-manifest.patch \
     0014-gcc-9-branch-clone_function_name_1-Retain-any-stdcall-suffix.patch

@@ -220,7 +219,7 @@ build() {

   make -j1 DESTDIR=${srcdir} install
   if [ "$_enable_ada" == "yes" ]; then
-    mv ${srcdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/adalib/*.dll ${srcdir}${MINGW_PREFIX}/bin/
+    cp ${srcdir}${MINGW_PREFIX}/lib/gcc/${MINGW_CHOST}/${pkgver%%+*}/adalib/*.dll ${srcdir}${MINGW_PREFIX}/bin/
   fi
 }

For reference, the diff from 0011-Enable-shared-gnat-implib.patch that this disables:

diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index e1ca515..133807e 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -2804,13 +2804,16 @@ gnatlib-shared-win32:
                $(PICFLAG_FOR_TARGET) \
                -o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
                $(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
-               $(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) $(MISCLIB)
+               $(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
+               -Wl,-out-implib,libgnat$(hyphen)$(LIBRARY_VERSION).dll.a \
+               $(MISCLIB)
        cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
                 | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` -shared -shared-libgcc \
                $(PICFLAG_FOR_TARGET) \
                -o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \
                $(GNATRTL_TASKING_OBJS) \
                $(SO_OPTS)libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \
+               -Wl,-out-implib,libgnarl$(hyphen)$(LIBRARY_VERSION).dll.a \
                $(THREADSLIB) -Wl,libgnat$(hyphen)$(LIBRARY_VERSION)$(soext)

 gnatlib-shared-darwin:
--

@steve-cs : yes, you got the right patch IMO. If one of you guys would submit it to msys2 that would be great. Feel free to e.g. copy me/reference me if needed, I can help pushing it.

I opened an issue there at
msys2/MINGW-packages#6181

I hope that is appropriate.

EDIT: just saw that @steve-cs already supplied it. I didn't see it in the list of issues there for some reason, so I closed mine.

Yeah, I just directly created a pull request without creating an issue and requested that Alexey review. I assumed a MSYS2 gcc problem would end up with him anyway. I've linked my pull request to your issue. Really shouldn't be a problem if that issue is left open or closed. People can discuss the problem (issue) or the proposed solution (pull request) in either place.

My bad, I should have tagged you directly in the pull request rather than assume you'd see the open PR here.

@steve-cs Oh it's my fault. I only saw the messages on my phone (email) which didn't show the pull request. I should have checked here first. After I submitted the issue at the msys2 repo, I came back to this repo to update and then saw it. I just need to slow down sometimes and take a look at things closer before I post stuff.

New gprbuild with the fix has been merged into msys2. The build should work now.

@reznikmm I hadn't seen that the fix (commit AdaCore/gprbuild@ada985f) had reached public. Thanks for the notice.

@steve-cs @reznikmm If I build gprbuild and xmlada from scratch (not using the bootstrap version of gprbuild in msys2) do I still need to do the manual fix to GCC or do the fixes also extend to the standard gprbuild repo on github?

The fix actually starts in the standard gprbuild repo on github (master branch only). If that works as expected, then my proposed manual fix (actually unfix) to GCC is not necessary and my pull request there can be closed/abandoned.

I expect that building gprbuild-bootstrap, xmlada, gprbuild, then gtkada from scratch using source from github/adacore/*/master will now build cleanly on MSYS2.

I'll be spinning up a MSYS2 system later today to confirm.

@jeremiahbreeden Confirmed working.