Hello,
We want to add French language to GPGOL component. I have seen this component is using gettext mechanism et .po files.
I have got GPGOL sources from GIT and tried to compile them on a Windows machine.
For this, I have installed MinGW environment (indicated on the readme file), then built libgpg-error, libassuan and gpgme libraries.
After that, I did not succeded to build GPGOL package (I got 2.2.5 version) and I am not sure of the way I used to produce “configure” file which is not present on the repository.
I think I missed something to build correctly this package.
Is there a document describing the process to build GPGOL on windows ?
Thanks for your help,
Hi Philippe,
Building on windows is not directly supported. We cross compile all binaries for gpg4win on Linux first. This does not mean it will not work but we don’t have documentation or experience with that.
GpgOL uses GNU Autotools to generate the configure file on a GNU/Linux system you would run ./autogen.sh to create it. A pregenerated version is already included in the source tarballs available from ftp://ftp.g10code.com/g10code/gpgol/
Can you give a more concrete problem how the build is failing for you? Maybe I can help.
Also please send us the french translation once you have it so that we can include it in new GpgOL versions.
Regards,
Andre
Hi Andre,
Thanks for your answer.
I tried to compile the tar comming from your ftp url that includes a configure file, and have the same issues.
In fact, in my previous trials, I produced the configure file using autogen.sh script. This script produces an error with the option --build-w32. It uses the command ‘mingw32’ that does not exist in MinGW and MSYS. Thus, I used it without this option to produce ‘configure’.
I have 2 issues during make execution :
- a little compilation error on ribbon-callbacks.cpp : constant UINT_MAX not defined (easy to correct)
- At the end of compilation, makefile tries to create symbolic links towards libgpg-error.a but MinGW has produced libgpg-error.dll.a and not libgpg-error.a during the compilation of this library. I don’t understant the difference between .dll.a and .a and the way to produce windows .dll in this process
Otherwise, all sources located in src directory are compiled. I am stuck at this step.
For sure, it was in my intention to deliver French version to the community. It was also another question for me, how to integrate it in a future standard version.
Thanks in advance,
Regard,
Philippe
- At the end of compilation, makefile tries to create symbolic links towards libgpg-error.a but MinGW has produced libgpg-error.dll.a and not libgpg-error.a during the compilation of this library. I don’t understant the difference between .dll.a and .a and the way to produce windows .dll in this process
GpgOL wants to statically link to libgpg-error, libgpgme and libassuan. For some reason it creates symlinks in it’s build directory instead of passing the absolute paths to the linker. (Probably some historic cruft).
libgpg-error.dll.a < This is the import library for a shared library. If you link against a dll.a you need the dll available at runtime.
libgpg-error.a < this is a static archive. Meaning the code from that library will be directly included in gpgol and you don’t need to have it available at runtime.
You should compile libgpg-error / gpgme and libassuan with --enable-static to get static archives for these libraries. The reason for static linking is that it makes the plugin loading of Outlook more robust as it only has to load gpgol.dll without it’s dependencies.
Libraries have been rebuilt using --enable-static. Symbolic links towards static libraries are now ok.
Final link operation fails with an error regarding multiple definition :
c:/mingw/bin/…/lib/gcc/mingw32/4.8.1/…/…/…/libuuid.a(unknow-uuid.o):unkwn-uuid.c:(.rdata+0x0): multiple definition of `IID_IUnknown’
olflange.o:olflange.cpp:(.rdata+0xd30): first define here
I think we are going to swtich to cross compile on Debian.
Thx,
Looks like your version of mingw already defines IID_IUnknown. You can probably remove the definition from olflange.cpp in that case.
This is what I have done after sending my message.
The library gpgol.dll is now built and can be loaded by outllook (curiously, its size is four times bigger than the original library, with the original library, it seems that libgpg-error, libassuan and gpgme are loaded dynamically as DLLs).
fr.po file has been defined and compiled, fr language has been added to ‘LINGUAS’ file and Makefiles have been rebuilt in order to take them into account. Nevertheless, at run time, French translation does’nt appear in the interface.
Is there something else to be done in order to take French language into account ?
The size is probably increased because the gpg4win strips the debug symbols from the library. No problem.
Was the .mo file compiled and is it installed in share\locale\fr\LC_MESSAGES\gpgol.mo ?
can you try starting outlook from the command line and doing:
set LANG=fr
Before executing it? Maybe the autodetection of the language is wrong. The environment variable LANG should take precendence then.
If you want you could send me your patch to aheinecke@intevation.de and I’ll have a look myself.
Yes,
I have done it this morning. Once .mo file put in the right place, localization works fine.
thank you !
We are going to completly translate the po file and qualify it.
We have also seen that kleopatra is not correcty available in French although it is completly in French on Linux/KDE (same version on both sides). I have put a .mo file comming from KDE on the same location and Kleopatra is now completly in French. GPG4Win seems not to get last French ressources for Kleopatra.
Do you know what is the process to deliver French ressouces to the GpgOL community so that a next version will include it ?
Thanks for the note about Kleopatra’s translation I’ll see to it that it’s updated.
To integrate your translation in gpgol you can either send it to me, add it as an attachment here or send it to the gpg4win-devel mailing list 
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-devel
gpg4win-devel is probably the best place for this. Preferably as a patch.