[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please test gsasl 0.2.29 release candidate!
From: |
Simon Josefsson |
Subject: |
Re: Please test gsasl 0.2.29 release candidate! |
Date: |
Sat, 11 Oct 2008 20:43:03 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux) |
Adam Strzelecki <address@hidden> writes:
> Simon,
>
> Please don't release 0.2.29 yet. I have serious concerns about sanity
> of latest changes.
Hi Adam! Thanks for looking at this.
> First of all MinGW has auto-export functionality, but it should be
> compatible with Windows __declspec(dllexport). So I wonder what was
> the errors while building in MinGW?
There are undefined references to import symbols when linking the
library:
/home/jas/libgsasl-0.2.28/src/init.c:57: undefined reference to
`__imp__gsasl_register'
.libs/init.o: In function `gsasl_init':
/home/jas/libgsasl-0.2.28/src/init.c:146: undefined reference to
`__imp__gsasl_done'
.libs/callback.o: In function `gsasl_callback':
/home/jas/libgsasl-0.2.28/src/callback.c:105: undefined reference to
`__imp__gsasl_server_callback_anonymous_get'
/home/jas/libgsasl-0.2.28/src/callback.c:121: undefined reference to
`__imp__gsasl_server_callback_securid_get'
/home/jas/libgsasl-0.2.28/src/callback.c:129: undefined reference to
`__imp__gsasl_property_set'
...
I suspect there actually is some incompatibility in using
__declspec(dllexport) with MinGW. Do you have any ideas?
Anyway, since MinGW doesn't require __declspec(dllexport), I would
prefer to not use it with MinGW unless there is a good reason.
> However if we want to limit GSASL_API to MS Visual C++ only, please
> bring back old GSASL_API block and just change:
>
> # if defined(_WIN32) && !defined(GSASL_STATIC)
>
> to
>
> # if defined(_MSC_VER) && !defined(GSASL_STATIC)
>
> but don't define GSASL_API inside of the VC project. Latest will
> probably beak VC projects relaing on libgsasl, since GSASL_API neither
> MSVC (which isn't standard macro) is not defined there (_MSC_VER is
> standard macro defined by Microsoft compiler). Also GSASL_EXPORTS &
> GSASL_EXPORTS matches Microsoft convention for building MSVC libraries
> (this is how M$ marks 99% of its projects and this is how Visual
> Studio macros create new library projects), having GSASL_API defined
> in project is against this.
> This convention isn't maybe wise & pretty but this is what MSVC
> programmer are used to.
I'll look into this approach.
> I'm fine with rest of the changes to drop Perl dependency. I remember
> you were asking for having this Perl script in gsasl as is was done in
> libidn though, and now we drop it back :>
I didn't know we could do without the perl script. :)
/Simon