help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANONYMOUS SASL profile


From: Francis Brosnan Blazquez
Subject: Re: ANONYMOUS SASL profile
Date: Wed, 14 Dec 2005 18:36:29 +0100

El mié, 14-12-2005 a las 16:14 +0100, Simon Josefsson escribió:

Hi Simon,

> > Well, I think we have to check what we are doing here because we
> where
> > getting some seg faults while reusing the same Gsasl context. That's
> why
> > we started to use a context (Gsasl *) and a session (Gsasl_session
> *)
> > for each connection.
> 
> Ok.  There shouldn't be any problem.  You will get crashes if you use
> Gsasl* instead of Gsasl_session*, perhaps you have other such errors?
> 

I'll take a look on this later. As you are pointing out, there are great
probabilities to be this.

> GNU SASL should also be thread safe for any normal use.  You can't
> invoke gsasl_step* for the same Gsasl_session in two threads at the
> same time, but I don't consider that normal use.

Ok, me too.

> 
> > Simon, thanks for your clear and quickly reply. 
> >
> > BTW, we are using GSASL for the BEEP stack [1] we are working on.
> You
> > could find it at: http://vortex.aspl.es. 
> 
> Thanks, I added a link to it on the GSASL home page.
> 

Great! I'm looking at http://www.gnu.org/software/gsasl/ and
http://josefsson.org/gsasl/ but I'm not able to find the Vortex Library
reference. Maybe I'm visiting the wrong GSASL home page.

> > Now that I have you at the other side let me ask you another
> question
> > not directly related to GSASL. 
> >
> > For win32 buildings which compiler/product are you using? The
> product we
> > actually use is mingw. Are you using this also?
> 
> Yes.  I am using mingw32 as distributed by Debian.
> 
> > I asking you this because we are having some annoying issues while
> > producing native dll on windows that is not produced with gcc.
> Actually,
> > gcc automatically (well, allows you) to export all symbols from your
> > library into the dll. But using other product such us Visual Studio
> you
> > need to do the standard voodo with dllimport/dllexport attributes
> (or
> > using G_MODULE_EXPORT from Glib which actually bounds to the same)
> or
> > especify a module definition (.def file).
> >
> > But reading how GSASL headers are written I've found that you are
> using
> > "extern" attribute rather than any non-sense stuff such as
> > G_MODULE_EXPORT.
> >
> > Our intention is to keep on using gcc (through mingw) to support
> Vortex
> > Library on win32, but it would be great to also support products
> such as
> > VS. The main problem with VS is that not providing
> dllimport/dllexport
> > stuff (or a .def file) cause not producing the import library
> (.lib). As
> > you know, this actually allows Win32 ISVs to link with the dll
> produced.
> >
> > How did you work around this issue on windows for GSASL?
> 
> Currently I only support mingw32, not VS.  If you can provide details
> on how to fix this in GSASL, I'll be happy to install any patches.
> Supporting VS seem like a useful thing, if doesn't cause any harm to
> anything else.
> 
> Some web searching revealed this:
> 
> http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/#dll-magic
> http://stud3.tuwien.ac.at/~e9725344/gtk/Building_HowTo.html
> 
> Perhaps it can be of any help...
> 

This is actually the method that are using the Gtk+/GLib devolpers. They
are still using mingw32 (or VS, it doesn't matter) but at the same time
they maintain the .def file adding/removing API entry points as needed.
This allows them to produce the import library file (.lib) while using
VS. 

Maybe this is the only method to keep on using mingw while keeping
Windows platform ISVs/software developers happy.

Thanks for your comments!

Cheers!

> Thanks,
> Simon
-- 
Francis Brosnan Blazquez <address@hidden>
Advanced Software Production Line, S.L.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]