Re: GNU SASL 0.2.28

[Simon Josefsson]

Francis Brosnan Blázquez <address@hidden> writes:

> Hi Simon!

Hi Francis!  I'm cc'ing the mailing list.

>> Hi Francis!  Thanks for your comments.  I have also noticed that Windows
>> builds have been failing under cross-compilation.  The changes made were
>> to accommodate the MSVS project files in lib/win32/.
>>
>> I've forgotten, how do you build gsasl under Windows?  MSVS, mingw,
>> cygwin, ...?
>
> I use mingw. Until this release it compiled perfectly; no problem.
>
> The last release I've checked before starting to use 0.2.28 was 0.2.24.

Ok, great.  I also use mingw, so I can fix the problems I had with mingw
compatibility, and they will likely be fixed for you as well.

>>> 1) At lib/src/gsasl.h:31, the new GSASL_API symbol depends on having
>>> defined GSASL_EXPORTS.
>>> Maybe I'm missing something, but compiling sources the same way as
>>> previous release do not include
>>> this symbol at the gcc flags. Therefore I compiled using:
>>>
>>>  >> ./configure CFLAGS="-DGSASL_EXPORTS"
>>>
>>> Digging a bit, it seems DLL_EXPORT is automatically defined by
>>> autotools on windows so,
>>> changing GSASL_EXPORTS by DLL_EXPORT also work, which is a better fix.
>>
>> GSASL_EXPORTS is intended to be set by the MSVS project files, and not
>> needed otherwise.  Do you need it?
>>
>> This is the problem that makes it break for me under mingw too, so I'm
>> going to revisit this.
>
> Having support for MSVS is great. Then this variable (GSASL_EXPORTS)
> should be defined by the configure.ac on windows (mingw/cygwin) to avoid
> passing the additional CFLAGS stuff..

Yup, I ran into this problem too, and didn't test mingw before the
release.

>>> 2) At src/internal.h:38, it is included poll.h. On windows this API is
>>> not available. I've updated
>>> the declaration with the following:
>>>
>>> #if !defined(_WIN32)
>>> # include <poll.h>  /* poll() */
>>> #endif
>>>
>>> 3) The next issue requires a bit more of work. Since poll API is not
>>> available, gsasl.c (around line 700)
>>> won't compile on windows. I've checked previous release (0.2.27) and
>>> it was using select(2).
>>> I didn't propose a path because I don't know your opinion about the
>>> approach to follow. My initial
>>> impression is that gsasl.c should use again select(2) as default.
>>
>> The idea was to use gnulib's upcoming poll module which works fine under
>> Windows too.  However, I know realize that if the select approach worked
>> under Windows, there is no point in that.  Did gsasl really work for you
>> before?
>
> I didn't check the gsasl.exe binary; only the library. Every time I build
> a gsasl release on windows, I run it against vortex regression test (which
> checks all profiles). Having fixed the GSASL_EXPORTS detail it also works
> (0.2.28).
>
> I'll check the gsasl.exe binary on next release and report the result.
>
>> I recall in GnuTLS that select was not able to select on both a
>> network connection and a tty under Windows.
>
> Certainly, select(2) winsock implementation do not allow mixing socket
> descriptors with anything else...I suffered this limitation in other
> project.

The library doesn't use select: only the command line uses it.

If I don't hear anything, I'm going to assume that gsasl.exe has never
worked under Windows, since I can't see how it would ever have worked
since winsock select cannot select between socket descriptors with tty
descriptors, and gsasl.exe has used select before 0.2.28.

Future versions of gsasl will use a gnulib module that implements a poll
that works under mingw with mixing tty and sockets.

>>> 4) I would recommend to include into the distribution the file
>>> src/gsasl_cmd.c generated by gengetopt
>>> because it would allow to not require to install this tool (to get
>>> gsasl compiled).
>>> In the other hand, I'm not able to successfully run this tool on
>>> windows to produce such file:
>>>
>>> gengetopt --unamed-opts="HOST [PORT]" \
>>>        --no-handle-version --no-handle-help \
>>>        --input gsasl.ggo --file-name gsasl_cmd
>>> c:\mingw\bin\gengetopt.exe: option `--unamed-opts' doesn't allow an
>>> argument
>>> Run gengetopt --help to see the list of options.
>>
>> It should be included:
>>
>> address@hidden:~/src/gsasl master$ tar tvfz
>> ../releases/gsasl/gsasl-0.2.28.tar.gz|grep _cmd
>> -rw-r--r-- 0/0           19516 2008-08-20 12:06
>> gsasl-0.2.28/src/gsasl_cmd.h
>> -rw-r--r-- 0/0           45853 2008-08-20 12:06
>> gsasl-0.2.28/src/gsasl_cmd.c
>> address@hidden:~/src/gsasl master$
>
> Uhmmn..my fault. It is included. I though this was the problem. I've been
> checking this issue but the configure process keeps on calling to
> gengetopt even having those files.
>
> I've updated the gengetopt command to look like:
>
>    gengetopt --unamed-opts \
>               --no-handle-version --no-handle-help \
>               --input $< --file-name gsasl_cmd
>
> ...but it still fails:
>
> gsasl.ggo:22: parse error s
> gsasl.ggo:22: section "Commands"
> gsasl.ggo:22:  ^
>
> The gengetopt version I'm using is:
>
> GNU gengetopt 2.8.1

That's quite old, I'm using 2.22.1.

> Removing the call to gengetopt and calling to make gsasl_cmd.o works
> properly. Maybe you can use the approach of manually update gsasl_cmd.*
> files (via make rule) rather letting the compilation process to always
> rebuild it.

This will complicate things for me, and what you are seeing is a bug so
it would be better to fix that bug instead of implementing work-arounds.
The bug is that make invokes gengetopt at all: in normal builds it
should never do so, unless you modified *.ggo files.

As a work-around on your side, you could try a more recent gengetopt. ;)

> Let me know if you need any data or check to perform.
> Cheers!

/Simon