MinGW / MSYS2 build fails for v0.26 with gcc 8.2.0

[emmenlau]

Since the upgrade to gcc 8.2.0 I can not build exiv2 anymore. Maybe someone here has experience or an idea about the problem? If not, we can maybe just leave this issue hanging for other people to share insight?

With gcc 8.2.0 on MSYS2 I get the following linker error:

cmd.exe /C "cd . && D:\bda-ci\msys2\bda\mingw64\bin\c++.exe -ggdb3 -O0 -m64 -march=nehalem -mtune=haswell  -DDEBUG -g  -m64 src/CMakeFiles/exiv2.dir/exiv2.cpp.obj src/CMakeFiles/exiv2.dir/actions.cpp.obj src/CMakeFiles/exiv2.dir/utils.cpp.obj src/CMakeFiles/exiv2.dir/localtime.c.obj  -o bin\exiv2.exe -Wl,--major-image-version,0,--minor-image-version,0  src/libexiv2.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
D:/bda-ci/msys2/bda/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/CMakeFiles/exiv2.dir/exiv2.cpp.obj: in function `Exiv2::BasicError<char>::BasicError<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
D:/Debug/Shared/exiv2-0.26/include/exiv2/error.hpp:282: undefined reference to `__imp__ZN5Exiv210BasicErrorIcE6setMsgEv'

I checked the symbols in libexiv2.dll and there the symbol is defined:

#> nm bin/libexiv2.dll | grep setMsg
000000006ed35174 T _ZN5Exiv210BasicErrorIcE6setMsgEv

I do not know why the linker step could fail, and why only for this symbol. Is there a chance that this is related to a char vs wchar issue? But I did not mix and mingle object files, this is one consistent clean build.

[D4N]

Is there a chance that this is related to a char vs wchar issue?

Unless you run cmake with -DEXIV2_ENABLE_WIN_UNICODE=ON, exiv2 will not use wchar. No clue where the linking error comes from though.

[clanmills]

731 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $ c++filt _ZN5Exiv210BasicErrorIcE6setMsgEv
Exiv2::BasicError<char>::setMsg()
732 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $ 

And that's in src/error.cpp:

732 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $ grep setMsg src/*.cpp
src/error.cpp:    void BasicError<char>::setMsg()
src/error.cpp:    void BasicError<wchar_t>::setMsg()
733 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $

The <wchar_t> variant is only compiled when using EXV_UNICODE_PATH
The <char> variant is always compiled. And, as you've reported, the symbol is in libexiv2.dll.

By happy coincidence, I want to do some maintenance work tomorrow on MinGW in preparation for v0.27 RC1 which I hope to publish in September. I have a puzzle to solve with MinGW/regex/version.cpp and I want to update the build notes concerning MinGW.

Let me see what I can discover and I'll give you an update tomorrow.

[clanmills]

Gentlemen:
I've build exiv2 on MinGW/64 with GCC 7.3.0. Looks good (with/without UNICODE)

bash-4.4$ uname -a
MSYS_NT-10.0 rmillsmm-w7 2.10.0(0.325/5/3) 2018-02-09 15:25 x86_64 Msys
bash-4.4$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 7.3.0
Copyright (C) 2017 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.
bash-4.4$ pwd
/home/rmills/gnu/github/exiv2/exiv2/build
bash-4.4$ find . -name "error.cpp.obj"
./src/CMakeFiles/exiv2lib.dir/error.cpp.obj
bash-4.4$ nm --demangle src/CMakeFiles/exiv2lib.dir/error.cpp.obj | grep setMsg
0000000000000132 T Exiv2::BasicError<char>::setMsg()
0000000000000390 T Exiv2::BasicError<wchar_t>::setMsg()
bash-4.4$

Incidentally there's code in config.h to refuse to build UNICODE with MinGW. Tobias (one of the darktable engineers) asked me to remove that. He's right. I'll deal with that tomorrow when I'm doing the MinGW maintenance. When you build the default (no UNICODE), you get one setMsg() entry point (as I deduced above by looking at the code).

This is a mysterious matter. I can't seriously entertain the idea that the name-mangler in GCC 8.2.0 is defective.

Today @D4N pointed me to a public/legal Windows 10 VM with Visual Studio. I'll use a nice clean machine tomorrow and install GCC 8.2.0.

[emmenlau]

Dear @clanmills , thanks! I'm super happy about your progress! I've previously used the build instructions from https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-exiv2/PKGBUILD but I don't know if they work around enabled/disabled UNICODE (most likely not). Any help is greatly appreciated.

I've also reported the issue here downstream here: https://github.com/Alexpux/MINGW-packages/issues/4338

[clanmills]

I'm pleased that you are pleased! I supported MinGW (msys/1.0) for Qt affectionados.

After we released v0.26 in April 2017, I came to the conclusion that MinGW (msys/1.0) was trouble, trouble, trouble. Even building CMake on MinGW required manually altering a Microsoft SDK header file.

Tobias assured me that MSYS2 worked, although I was unable to build Exiv2 on that platform. A discussion with @Hombre57 in June 2018 resolved that and MSYS2 now builds OK. #370

I will read the Alexpux document tomorrow when I update README.md with the information in #370.

Fixing config.h is trivial. Comment off the error line:

742 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $ nl -b a include/exiv2/config.h | grep -A 1 -B 1 error -
   155	#ifdef EXV_UNICODE_PATH
   156	#error EXV_UNICODE_PATH is not supported for MinGW builds
   157	#endif
743 rmills@rmillsmbp:~/gnu/github/exiv2/exiv2 $ 

I hope to submit that (and other fixes) tomorrow.

[piponazo]

I just noticed something suspicious in your error line: Exiv2::BasicError<char>::BasicError<std::__cxx11::basic_string<...`. That cxx11 makes me think that you might have some miss configuration in the way the project is configured. Remember that Exiv2 must be compiled with the C++98 standard.

Since gcc6, the default standard is c++14: https://gcc.gnu.org/gcc-6/changes.html

[clanmills]

Good Idea @piponazo The output from CMake is setting -std==gnu++98

631 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $ cmake .. -G "Unix Makefiles"
...
-- Compiler flags
-- General:            -Wall -Wcast-align -Wpointer-arith -Wformat-security -Wmissing-format-attribute -Woverloaded-virtual -W -std=gnu++98
-- Extra:
-- Debug:             -g3 -gstrict-dwarf -O0
-- Release:           -O3 -DNDEBUG
-- RelWithDebInfo:    -O2 -g -DNDEBUG
-- MinSizeRel:        -Os -DNDEBUG
...
-- Compiler info: GNU (C:/msys64/mingw64/bin/c++.exe) ; version: 7.3.0
...

It's really strange that the library has the symbol and it doesn't link itself! And it's only this one symbol. How odd!

635 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $ nm --demangle lib/libexiv2.dll.a | grep setMsg
0000000000000000 I __imp__ZN5Exiv210BasicErrorIcE6setMsgEv
0000000000000000 T Exiv2::BasicError<char>::setMsg()
636 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $

I've been delayed by various matters (and had lots of help from @D4N and @piponazo). Hope to install GCC 8.2.0 on a clean machine on Sunday afternoon.

[emmenlau]

I will check my configuration with respect to c++ standard. It is actually something I usually take care, to not mix and mingle too many standards, so there are some libraries where I set c++11 or 14. I'll check about exiv2, thanks for the very good pointer!

[clanmills]

I've reproduced this on a 'clean' machine. pacman installed GCC 8.2.0. I don't know how to "downgrade" the compiler. https://stackoverflow.com/questions/33969803/how-to-obtain-older-versions-of-packages-using-msys2

[ 49%] Building CXX object src/CMakeFiles/exiv2lib.dir/pngimage.cpp.obj
[ 49%] Linking CXX shared library ../bin/libexiv2.dll
[ 49%] Built target exiv2lib
Scanning dependencies of target exiv2
[ 50%] Building CXX object src/CMakeFiles/exiv2.dir/exiv2.cpp.obj
[ 51%] Building CXX object src/CMakeFiles/exiv2.dir/actions.cpp.obj
[ 51%] Building CXX object src/CMakeFiles/exiv2.dir/getopt.cpp.obj
[ 52%] Building CXX object src/CMakeFiles/exiv2.dir/utils.cpp.obj
[ 52%] Linking CXX executable ../bin/exiv2.exe
CMakeFiles/exiv2.dir/objects.a(exiv2.cpp.obj):exiv2.cpp:(.text$_ZN5Exiv210BasicErrorIcEC1INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEENS_9ErrorCodeERKT_[_ZN5Exiv210BasicErrorIcEC1INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEENS_9ErrorCodeERKT_]+0x93): undefined reference to `__imp__ZN5Exiv210BasicErrorIcE6setMsgEv'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/exiv2.dir/build.make:139: bin/exiv2.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:327: src/CMakeFiles/exiv2.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

There's a significant difference in the symbols On 8.2.0 we see:

70 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $ nm -g --demangle bin/libexiv2.dll | grep setMsg
000000006c6649b2 T Exiv2::BasicError<char>::setMsg()
71 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $

On 7.3.0, we see:

635 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $ nm --demangle lib/libexiv2.dll.a | grep setMsg
0000000000000000 I __imp__ZN5Exiv210BasicErrorIcE6setMsgEv
0000000000000000 T Exiv2::BasicError<char>::setMsg()
636 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $

Note: 7.3.0 has BOTH ...setMsg and __imp...setMsgEv

The library doesn't have the entry __imp__ZN5Exiv210BasicErrorIcE6setMsgEv which is the missing entry reported by the linker in 8.2.0.

It feels as though something in 8.2.0 is causing __imp__ZN5Exiv210BasicErrorIcE6setMsgEv to be invisible. Incidentally, this is very similar to a MinGW linking issue which was investigated earlier today. In that case, we side-stepped the linking issue as it involved linked an obsolete program in samples. #431

It's been a long day. I'll continue to investigate on Monday.

[emmenlau]

Dear @clanmills , thanks for your detailed investigation, this is very interesting! To save some of your time, maybe it would now be time to involve some MSYS2 / MinGW core people in the discussion? Since the problem you found is so fundamental it may be a known issue? The MSYS2 mailing list (https://sourceforge.net/p/msys2/mailman/) may be a good place for discussion...

[clanmills]

I think this is a GCC issue. MinGW appears to be working fine. My suspicion is the compiler. Yesterday, when working on #421, I discovered entry points in Exiv2::Internal::Util were no longer in the library.

We build the library as two entities:

add_library( exiv2lib_int OBJECT ${LIBEXIV2_PRIVATE_SRC} ${LIBEXIV2_PRIVATE_HDR})
add_library( exiv2lib ${LIBEXIV2_SRC} ${LIBEXIV2_HDR} $<TARGET_OBJECTS:exiv2lib_int>)

I'm not an expert in CMake. I not sure how those are combined into a single library. I think the second add_library does the job. However I'm wondering if something causes the symbols in exiv2lib_int to be hidden during the combination process. Yesterday, in pursuit of #412, I moved missing entries from exiv2lib to exiv2lib_int without success. With #412, I took the easy way out which was to ask @piponazo to remove dead code in samples/ and that's what he did with #431

This evening I will:

1. Build the whole library as exiv2lib (without exiv2lib_int) and see if that solves this puzzle (I suspect it will not).
2. Investigate the difference between the stub/library (libexiv2.dll.a) on GCC 7.3.0 and 8.2.0
3. We're dealing with __imp__ZN5Exiv210BasicErrorIcE6setMsgEv which nm displays as type I and not T. I think I is an interface, and T is an enTry point. Something to ponder.
4. The Mac builds intermediate targets build/lib/.../libxmp.a and build/src/..../libexiv2lib_int.a MinGW builds src/.../exiv2.dir/objects.a and src/.../exiv2lib.dir/objects.a Where's exiv2lib_int.dir/objects.a which might have the missing entry? More digging needed.

In the process of investigating those four subjects, I'll probably have more ideas.

I'd prefer not to involve the MinGW/GCC forum in this investigation until I have run out of ideas for investigation as this will create even more email/discussion. Let's see what another day brings.

[clanmills]

There's no question about the problem.
On GCC 7.3.0

558 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $ nm --demangle lib/libexiv2.dll.a | grep setM
0000000000000000 I __imp__ZN5Exiv25Image11setMetadataERKS0_
0000000000000000 T Exiv2::Image::setMetadata(Exiv2::Image const&)
0000000000000000 I __imp__ZN5Exiv210BasicErrorIcE6setMsgEv
0000000000000000 T Exiv2::BasicError<char>::setMsg()
559 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $

On 8.2.0

109 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $ nm --demangle lib/libexiv2.dll.a | grep setM
0000000000000000 I __imp__ZN5Exiv25Image11setMetadataERKS0_
0000000000000000 T Exiv2::Image::setMetadata(Exiv2::Image const&)
110 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $

The entry point is missing in 8.2.0. I don't know why it's missing. I'll do more work this evening.

[clanmills]

I've eliminated the following:

1. It cannot be exiv2lib/exiv2lib_int visibility/conflict. The entry is in error.cpp which is in exiv2lib
2. I've explored the declaration without success by making it public in include/exiv2/error.hpp
   I've also tried about 6 modifications to EXIV2API in config.h

    private:
        //! @name Manipulators
        //@{
        //! Assemble the error message from the arguments
        EXIV2API void setMsg();
        //@}

Running out of ideas. Why is this function a template? Perhaps a regular function, or an inline will fix this.

[clanmills]

Eureka. Static libraries build OK!

$ cd build
$ cmake .. -DBUILD_SHARED_LIBS=Off -G "Unix Makefiles"
$ make
...
69 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $ bin/exiv2 -vV -g version -g ^dll -g compiler -g platform
exiv2 0.26 001a00 (64 bit build)
platform=mingw64
compiler=G++
dll=0
version=8.2.0
70 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $

There something wrong with GCC/linker when it creates libexiv2.dll (and libexiv2.dll.a).

The application exiv2.exe is in src/exiv2.cpp and links libexiv2.dll.a which doesn't have the import symbol __imp__ZN5Exiv210BasicErrorIcE6setMsgEv. It's a linker error in the construction of libexiv2.dll (and libexiv2.dll.a). I suspect GCC 7.3.0 manufactures this symbol so that the application (exiv2.exe) can access Exiv2::BasicError::setMsg() in the DLL. This 'thunking' isn't required with static libraries and that's why everything works when I build static libraries.

I'm not sure if this is restricted to MinGW, or applies to GCC8 on Linux and/or Cygwin.

I'm working hard to release Exiv2 v0.27 RC1 in September and it's been great to explore this issue on MinGW/msys2. To make the schedule, I have to document MinGW/msys2 requiring GCC 7.3.0. I'll put in the release notes that there is an outstanding issue with GCC8 and reference this discussion.

May I ask you to take up this case with the GCC team. I hope we can find a solution for Exiv2 v0.27 GM which we hope to release at the end of 2018.

[clanmills]

Thank you for reporting this to Alexpux/MINGW-packages. I really like your precise definition of the puzzle.

The dll symbols are quite different for exiv2 since gcc-8.2. Is this known or expected?

On GCC 7.3.0:

558 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $ nm --demangle lib/libexiv2.dll.a | grep setM
0000000000000000 I __imp__ZN5Exiv25Image11setMetadataERKS0_
0000000000000000 T Exiv2::Image::setMetadata(Exiv2::Image const&)
0000000000000000 I __imp__ZN5Exiv210BasicErrorIcE6setMsgEv
0000000000000000 T Exiv2::BasicError<char>::setMsg()
559 rmills@rmillsmm-w7:~/gnu/github/exiv2/exiv2/build $

On 8.2.0:

109 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $ nm --demangle lib/libexiv2.dll.a | grep setM
0000000000000000 I __imp__ZN5Exiv25Image11setMetadataERKS0_
0000000000000000 T Exiv2::Image::setMetadata(Exiv2::Image const&)
110 User@WinDev1808Eval:~/gnu/github/exiv2/exiv2/build $

[piponazo]

I would like to also report that I have recently experienced this issue.

In MSYS2, the gcc package for 64 bits is gcc-8.2 while the one for 32 bits is gcc-7.2. With gcc-7.2 I can compile the full project without issues, but I stumbled into this linking error with gcc-8.2.

@clanmills I think it would be good to point to this issue somewhere in the documentation you are writing in the RC1 branch.

[clanmills]

@piponazo For sure, this is going in the documentation.

I've made good progress towards RC1 this week. The road is longer than I wanted/imagined. I have written a script (contrib/buildserver/build.sh) build all the packages on the 5 platforms (macosx, linux, cygwin, mingw and msvc). Next, I will fix the localtime/gmtime business for Gilles. Then I'll tackle the website and doxygen. There's still lots to do. I hope we'll have RC1 out in October and GM at the end of the year.

Gilles added a load of work this week with the Exiv2Tags::groupList() and localtime.c. However it's good to have Gilles report these matters, because they would have appeared eventually. It's very unfortunate that Exiv2Tags::groupList() revealed a problem with Xcode 10.0. These things happen.

[cgilles]

When do you plan to release the 0.27 RC1 exactly ?
We are near to be ready to release digiKam 6.0.0-beta2. I can plan to release this version at the same time than digiKam and include the Exiv2 announcement to digiKam release announcement from digiKam.org. We can delay a little bit if necessary.

Gilles Caulier

[clanmills]

I don't have an exact plan. I'm at home and working on this most of the time. I hope RC1 will be released by the end of October and GM by the end of December.

You'll be aware that groupList() and localtime.c and other matters consumed a lot of time this week. And my wife's brother passed away yesterday.

There are several major obstacles:

1. The web-site scripts (which I inherited from Andreas) need a lot of work.
2. I am quite unable to use Git and this makes progress very painful.
3. The move to Git totally destroyed our jenkins build server and I hope to fix that this week.
4. The scripts to manage bugs, release notes and project status operate on our redmine server. I don't know yet how to generate a good list of outstanding issues on GitHub to be fixed.
5. And, as you know, every week brings new unexpected tasks.

So, please be patient. I'm working on it. @piponazo and @D4N have been very helpful.

[phako]

Isn't the missing BasicError issue basically the same as #644 ?

[clanmills]

@phako You could be correct. The investigation here was on a Microsoft VM with a short (90 day?) license. I don't want to install GCC 8.2 on our Windows Buildserver (nor my laptop). I'll get a "fresh" VM from Microsoft and look at this. It would be great to get this solved.

[D4N]

Hey folks, I have recently tried to cross compile exiv2 with mingw on Fedora (also with gcc 8.2.) and I am seeing exactly the same error as @emmenlau. The error only pops up when building a shared library, with a static library everything is fine. The resulting binary actually runs on Linux with wine and with some tweaking and cheating it might even pass the test suite.

The culprit of this is BasicError<charT>::setMsg(), which is an exported function in a template class (which of course is not exported). Unfortunately, we have to export it, as it is used in the header and if you drop the export you'll immediately get linking errors. The simplest solution would be to implement setMsg() in the header. But that is not an option either, as setMsg() is responsible for localization that must happen inside the library (since we don't want to expose the internals of that to the outside).

I have yet to come up with a good solution for this, but I am afraid there is none. The imho best solution would be to just drop BasicError<wchar_t> and remove the templating. Then we can hide everything inside the library and the problem will be gone. BasicError<wchar_t> isn't used a lot inside of exiv2 and only if you set EXV_UNICODE_PATH, which I doubt a lot of people actually do (our CI FYI doesn't). But someone more familiar with Windows and their handling of encoding should double check first.

[clanmills]

I agree with you Dan. I had that conversation with @piponazo earlier this week. I suspect that class was "templatized" when UNICODE_PATH was added. The wchar stuff is only to pass the pathname when a file doesn't open. I believe we can use EXIV2API std::string ws2s(const std::wstring& s); to avoid passing wstring/wstr into the error classes. The template is not worth the pain it's causing.

I've installed a new Windows 10 VM on Parallels and (avr-)GCC 8.2 won't build anything. Puzzled.

[clanmills]

By the way, Dan. I'm confident that we will be able to run the test suite with wine on Linux. I intend that our GSoC student will deal with that when we adopt CTest and replace the bash scripts with your python code.

[Jehan]

Hi! Any chance this will get a happy ending? :-)

I can have Exiv2 build with GCC 8.3.0 if I simply comment out the 4 calls to setMsg() inside src/error.cpp. I have a hard time understanding exactly why the linking errors though. If really a GCC bug, has a report been opened there?

[D4N]

Jehan <notifications@github.com> writes:

Hi! Any chance this will get a happy ending? :-)

Not for 0.26, that one is out of maintenance. For the upcoming 0.28 release we'll hopefully have #685 merged, which should fix this issue properly.

I can have Exiv2 build with GCC 8.3.0 if I simply comment out the 4 calls to `setMsg()` inside `src/error.cpp`. I have a hard time understanding exactly why the linking errors though. If really a GCC bug, has a report been opened there?

This is not a gcc bug, the issue is that we are mixing hidden visibility and templates and that is a recipe for disaster (at least on Windows).

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #421 (comment)

[clanmills]

If really a GCC bug, has a report been opened there?

Yes, this was raised with the GCC folks (by our user). However I'm not aware of a response. I trust Dan's judgement that visibility/templates are the culprit.

[Jehan]

Not for 0.26, that one is out of maintenance.

Yeah I encountered the problem with last master commit. Should have mentioned that. ;-)

For the upcoming 0.28 release we'll hopefully have #685 merged, which should fix this issue properly.

Awesome. Looking forward to this.

This is not a gcc bug, the issue is that we are mixing hidden visibility and templates and that is a recipe for disaster (at least on Windows).

Ok.

[clanmills]

Folks. Here's the "discussion" of the issue:

msys2/MINGW-packages#4338

As you can see, sadly nobody investigated! I'm very proud of Team Exiv2. We quickly and thoroughly investigate everything reported. This issue is tough.

@D4N is this solved on 'master'?

[D4N]

Robin Mills <notifications@github.com> writes:

@D4N is this solved on 'master'?

No, as #685 has not been merged yet. Need to rebase it on top of master and see if it still builds.

[clanmills]

I think we can close this now as historical trouble.