Build fails if EXIV2_ENABLE_BUILD_PO=TRUE #14
Comments
|
I've never looked at this. I have to confess that localisation is a total mystery to me. There is a switch EXIV2_ENABLE_NLS to deal with "Natural Language Something". I usually keep that off! I'll have a look at this. |
|
I can't reproduce this, even with a fresh It looks to me as though you trying to execute msgmerge on non-existent May I ask you to try a fresh git clone and send me a longer transcript of the issue. |
|
I used the exiv-v0.26-trunk.tar.gz archives for building, maybe you can reproduce it that way? |
|
Right. I'm on the same page although I can't reproduce the po file grumbles. There is an issue with how the released code and handles LIBINTL. This issue causes link failures in the the library and the exiv2(.exe) application. Changes are required in config/CMakeChecks.txt and src/CMakeLists.txt to fix this. In the past, I've always built with -DEXIV2_ENABLE_NLS=FALSE I received a patch recently which repaired ENABLE_NLS and that's what you'll need. Can you look in /po. Here's what I have: |
|
Looks like I've got some more files under po, looks OSX specific: |
|
Indeed, that was it, |
|
Holly crap. These horrid _* files have been put there by Apple's version of tar. I think they hold extended file attributes used by the Apple file system. When I untar the bundle on the Mac, I don't see them because Apple swallow them back into the filesystem. Crap, crap, crap. I had totally forgotten about that behaviour of Apple's tar. This has caused me heartache on clanmills.com for reasons we will not discuss. And of course, as they are .files, they're hidden by default on Linux. I will fix the buildserver to create "pure" tars which don't have those hidden idiotic files. https://superuser.com/questions/61185/why-do-i-get-files-like-foo-in-my-tarball-on-os-x Perhaps I should think about fixing the published bundles. Looks like the 0.26.1 dot release is becoming urgent. |
|
I've committed the fix for the buildserver. I'm not going to do anything instantly about the released bundles. I'm going hill walking tomorrow morning and I'll think about this (and then probably fix them tomorrow afternoon). Can you help me with GitHub? I know from the git log that the patch concerning LIBINTL is #8. However I can't locate #8. Do you have any idea where it's hiding? |
That's fine for me, the workaround is pretty simple anyway.
|
|
I've fixed the source download archive I've updated the file size and md5sum. I did this manually on Linux by extracting I've inspected the archives for cygwin, mingw, msvc, linux, and macosx. Because the archives were created on their own platform, only macosx has ._mumble files . This is acceptable as the archive is intended for use on MacOSX. I have verified that the command prefix Finally, as we don't distribute the test directory in the source archive, I copied it from my current copy of master. When I ran the test suite, the validity of the change to test/data/preview/preview-test.out yesterday in support of #16 was confirmed. I'm going to reward myself with a cup of coffee. I'm going to now give attention to CMake/MSVC/static external libraries #11 |
It looks like it tries to generate a file that does not make sense:
The text was updated successfully, but these errors were encountered: