search

cppit / jucipp

A lightweight & cross-platform IDE supporting the most recent C++ standards. This project has moved to https://gitlab.com/cppit/jucipp.
https://gitlab.com/cppit/jucipp
MIT License
882 stars 98 forks source link

MSYS2: recent build and linking problems, and segmentation faults #172

Closed oalbe closed 8 years ago

oalbe commented 8 years ago

Hey there,

I hate bothering but I figured this has the potential to be something you might be interested in knowing, so I convinced myself in posting it.

I was very interested in trying Juci so I went through the step-by-step instructions you wrote about building and running it. I did everything the exact same way you suggested, but things went south anyway.

Basically, everything goes smoothly during compilation. No complains from CMake, no problems with MSYS2. The problem happens when I try to run it. If I run it from the shell, it just says some library is missing. When I try executing from Explorer instead, it complains about a specific missing library (libicuuc56).

C:/dev/msys64/mingw32/bin/juci.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

So I passed the executable through Dependency Walker, and I discovered that there are actually 7 things that seem to be missing (specifically, DW says for each of those: Error opening file. The system cannot find the file specified(2)):

I checked the bin/ folder, and there actually is a libicuuc dll, but it's 55 instead of 56. I have no idea where this dll comes from, so I don't know how to fix it and try again.

Some details:

[100%] Built target juci
Install the project...
-- Install configuration: ""
-- Installing: C:/dev/msys64/mingw32/bin/juci.exe

I think it's everything. If there are other details you might need, don't hesitate to ask, I'll be happy to provide them.

eidheim commented 8 years ago

I managed to get the needed dll's by running (from where you ran your git command):

objdump -p ./jucipp/build/src/juci.exe |grep "DLL Name"

My output is as follows:

        DLL Name: libaspell-15.dll
        DLL Name: libatkmm-1.6-1.dll
        DLL Name: libboost_filesystem-mt.dll
        DLL Name: libboost_log-mt.dll
        DLL Name: libboost_regex-mt.dll
        DLL Name: libboost_system-mt.dll
        DLL Name: libboost_thread-mt.dll
        DLL Name: libclang.dll
        DLL Name: libgdk-3-0.dll
        DLL Name: libgdkmm-3.0-1.dll
        DLL Name: libgio-2.0-0.dll
        DLL Name: libgiomm-2.4-1.dll
        DLL Name: libglib-2.0-0.dll
        DLL Name: libglibmm-2.4-1.dll
        DLL Name: libgobject-2.0-0.dll
        DLL Name: libgtk-3-0.dll
        DLL Name: libgtkmm-3.0-1.dll
        DLL Name: libgtksourceview-3.0-1.dll
        DLL Name: libgtksourceviewmm-3.0-0.dll
        DLL Name: libpangomm-1.4-1.dll
        DLL Name: libsigc-2.0-0.dll
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: libwinpthread-1.dll
        DLL Name: USER32.dll
        DLL Name: libgcc_s_seh-1.dll
        DLL Name: libstdc++-6.dll

Is your output similar? However, I ran pacman -Suy Today. Some of the issues in MSYS2 earlier has been related to not having upgraded MSYS2.

oalbe commented 8 years ago

I ran that command, and the output is actually almost identical (it changed the order of some DLLs actually, but I assume that doesn't count).

The only difference was that my output has this library: DLL Name: libgcc_s_dw2-1.dll while yours has this one: DLL Name: libgcc_s_seh-1.dll.

Yeah I thought about upgrading the whole MSYS2, problem is that I don't have a great connection at hand at the moment, so it would take a while. (I'll try doing it tomorrow in the morning if the connection doesn't decide to crash)

eidheim commented 8 years ago

Hope that fixes it. You probably have to remove the build directory and run cmake and make again for juci to work after the upgrade. And make sure to run juci from the correct mingw shell, but I guess you know that:)

eidheim commented 8 years ago

You might have to restart the mingw shell too after the upgrade.

eidheim commented 8 years ago

Due to MSYS2 upgrade to gtk3.20 packages Tonight, juCi++ is currently broken on a freshly upgraded MSYS2. I'll have a look if there is a quick fix for this.

oalbe commented 8 years ago

Oh, cool, so this is why at some point even gtkmm3 was complaining about missing libraries. Too bad I already went the way of making a clean installation of MSYS2 because I thought I made a mess. Glad to know it wasn't due to me possibly breaking things.

I'll wait :)

eidheim commented 8 years ago

Follow https://github.com/Alexpux/MINGW-packages/issues/1236

Regarding the cmake gtkmm3 issue, pkg-config --exists --print-errors gtkmm-3.0 gave this output:Package 'libpcre', required by 'glib-2.0', not found". However this is resolved by installing mingw-w64-pcre.

eidheim commented 8 years ago

I posted this bug at GNOME Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764233

eidheim commented 8 years ago

Getting close to a fix, but gtksourceview3 probably have to release gtksourceview3.20.1 for it to work on Windows. However, if that takes time, I could add a couple of patches to the current MSYS2 gtksourceview3 package and ask for rebuild.

eidheim commented 8 years ago

There is also a segmentation fault when running juCi++ in MSYS2, but that is easy to fix compared to GTK macros! I'll fix the segmentation fault later.

oalbe commented 8 years ago

Great news!

It shouldn't be that hard to add the patches to the MSYS2 packages during the build process (I learned how to do it and it's not hard at all). So even the patch route might be feasible.

About the segmentation fault: does that happen only when running juCi++ in MSYS2? How so?

eidheim commented 8 years ago

Sorry for being a bit lazy, but hoping they will bump the gtksourceview micro version because of the two patches (https://bugzilla.gnome.org/show_bug.cgi?id=764246 and https://bugzilla.gnome.org/show_bug.cgi?id=764263). Or else they do not have a working Windows port.

I have not looked at the segmentation fault yet, but its due to the MSYS2 package upgrades the other day. Feel free to investigate, I'm taking a break Tonight, these gtk minor version upgrades are time consuming!

eidheim commented 8 years ago

Ok, I looked a bit on the segmentation fault, and it seems there are several issues. For some reason only boost::property_tree::ptree::get<std::string> is working, that is not ...<bool> for instance. And, after fixing the ptree issue, when opening a file, another segmentation fault is within filesystem::read_non_utf8 (src/filesystem.cc). I'll probably fix these things Tomorrow.

eidheim commented 8 years ago

Removing -O3 from top of src/CMakeLists.txt fixes most of the segmentation faults. However, clang_CompilationDatabase_fromDirectory from libclang still causes segmentation fault.

eidheim commented 8 years ago

All right, we are getting close to a working MSYS2 version again! Give it a day or two.

eidheim commented 8 years ago

The issues has been solved. Just waiting for https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gtksourceview3 to be rebuilt (probably Tonight). Closing this issue then.

oalbe commented 8 years ago

That's great! I wish I was able to have been of any help in this.

eidheim commented 8 years ago

Still waiting for mingw-w64-gtksourceview3 to be rebuilt for version 3.20.1. Do you know how MSYS2 queue their builds? Have not been able to find any information on this.

eidheim commented 8 years ago

Upgrade with MSYS2 with Pacman -Syuu, and you should now be able to install juCi++ on MSYS2 when following the installation instructions:)

oalbe commented 8 years ago

Do you know how MSYS2 queue their builds?

Mh, I don't know how the guys queue builds, but I doubt they actually have a queue. You can try asking in #msys2 on OFTC.net network. They are all nice people :)

I'll try the upgrade and the new installation as soon as possible (which probably means on Sunday, unfortunately :/) let's keep finger crossed. Thanks for the interest and the help!