Mailing List Archive: GnuPG: devel

fixes for Msys+Mingw

Index | Next | Previous | View Threaded

carlo.bramix at libero

Aug 26, 2008, 9:40 AM

Post #1 of 3 (200 views)
Permalink

fixes for Msys+Mingw

Hello,
I tried to compile gnupg 2.0.9 under Mingw+Msys.
I got some little troubles that I fixed in my build.
I attached a patch to this email.

Description of changes:

1- /jnlib/utf8conv.c was compiled successfully, but it was not working because because "iconv.dll" was not found during runtime.
But it exists just with a different name, mine is called "libiconv-2.dll".
I believe that it's a good idea to use ICONV correctly if it's found.
Since Msys is a posix-like enviroment under Windows, AM_ICONV detects its presence at configure time and it adds "-liconv" to LDFLAGS.
So, if that shared library exists, the executables are linked directly with the import library and it is absolutely not required to dynamically load it.

2- compilation of scd/ccid-driver.c failed because ETIMEDOUT is undefined in Windows.
However, LibUSB-Win32 do not set errno, but it encodes the error code directly into the return value of the functions.
So the test on errno happens only on platforms different from W32.

I hope you will find it useful.

Sincerely,

Carlo Bramini.

Attachments:

gnupg.txt (2.20 KB)

wk at gnupg

Sep 1, 2008, 7:28 AM

Post #2 of 3 (178 views)
Permalink

Re: fixes for Msys+Mingw [In reply to]

On Tue, 26 Aug 2008 18:40, carlo.bramix[at]libero.it said:

> I tried to compile gnupg 2.0.9 under Mingw+Msys.

Not a supported build platform, but let's see:

> 1- /jnlib/utf8conv.c was compiled successfully, but it was not working because because "iconv.dll" was not found during runtime.
> But it exists just with a different name, mine is called "libiconv-2.dll".
> I believe that it's a good idea to use ICONV correctly if it's found.
> Since Msys is a posix-like enviroment under Windows, AM_ICONV detects its presence at configure time and it adds "-liconv" to LDFLAGS.

Well, if Msys is the build platform the it needs to support
corss-compilation. You need to build gnupg the same way as on a real
Posix platform, that is you should use build commands similar to what
"./autogen.sh --build-w32" uses.

> So, if that shared library exists, the executables are linked directly with the import library and it is absolutely not required to dynamically load it.

Not a good idea. For one we want to have close control over what DLLs
are used and second it should be piossible to do without inconv.dll.

> 2- compilation of scd/ccid-driver.c failed because ETIMEDOUT is undefined in Windows.
> However, LibUSB-Win32 do not set errno, but it encodes the error code directly into the return value of the functions.

Interesting. There is a working port of libusb now? Any pointers - I
am very interested. We don't support the internal CCID driver under
Windows. Anyway it is a bug in that port if it does not set ERRNO
properly.

It is also a cross-building problem; you need to decide whether you want
a POSIX version of GnuPG (like Cygwin) or a native one.

Salam-Shalom,

Werner

--
Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org

Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel[at]gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

carlo.bramix at libero

Sep 3, 2008, 4:19 AM

Post #3 of 3 (173 views)
Permalink

Re: fixes for Msys+Mingw [In reply to]

Hello!

>> So, if that shared library exists, the executables are linked directly with the import library and it is absolutely not required to dynamically load it.
>
> Not a good idea. For one we want to have close control over what DLLs
> are used and second it should be piossible to do without inconv.dll.

I understand your needs.
However, if I understood correctly the sources, everything is decided by the presence of HAVE_ICONV.
So the code should be still work as now if you configure it in the right manner.
If this macro is not declared then it will work exactly as it was previously.
If some people built GnuPG with MSVC, they won't need to add HAVE_ICONV into their project properties and afterall I do not think that they did it.
So you could see it as a fix only for Windows' posix enviroments, if you want.
In the future we may eventually force the same behaviour even with (but not limited to) Msys by adding to configure script an option like "--disable-iconv" and call AM_ICONV only if it's enabled.
I also forgot to tell you that I was not able to make it working on CYGWIN too, because that library is called cygiconv-2.dll
If I can give you my opinion, the ability to work with iconv as import library *in addition* to current LoadLibrary() method is strongly recommended.

>> 2- compilation of scd/ccid-driver.c failed because ETIMEDOUT is undefined in Windows.
>> However, LibUSB-Win32 do not set errno, but it encodes the error code directly into the return value of the functions.
>
> Interesting. There is a working port of libusb now? Any pointers - I
> am very interested. We don't support the internal CCID driver under
> Windows. Anyway it is a bug in that port if it does not set ERRNO
> properly.

Yes, it exists by looong time at http://libusb-win32.sourceforge.net
Last time I used it, the error value was encoded into the return value of the functions because there is no way to write _errno from old MSVCRT.
I do not think that changed, however it may be possible that the handling of error codes evolved in these last years...
Perhaps error codes are also reported with Win32 API like GetLastError/SetLastError, it should be read from latest sources of LibUSB-Win32.

Sincerely,

Carlo Bramini.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel[at]gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com