Commit Graph

14 Commits

Author SHA1 Message Date
Fabrice Fontaine
2eb3e069ba Remove more implicit casts in upnp part
Remove more "implicit integer or enum conversions" as well as memset
before snprintf.
2012-03-10 22:52:57 +01:00
Iain Denniston
fed316ff3e Several fixes to correctly use SOCKET (and related) types instead of non-portable variations. 2011-04-02 23:38:53 -03:00
Iain Denniston
840669b253 Fixes for headers when compiled under C++ 2011-03-11 16:07:51 -03:00
Marcelo Roberto Jimenez
f67ed1949b Less include file mess and doxygenation. 2010-12-19 19:02:42 -02:00
Marcelo Roberto Jimenez
04d64a893b Doxygenation of SSDP library. 2010-12-19 13:41:58 -02:00
Marcelo Roberto Jimenez
b2a88aa70b SF Tracker: Patches - Fedora mingw32 compilation - ID: 3138849
Details:
Hello. I trying compile libupnp-1.6.10 on the Fedora 14 MinGW
Environment and get many errors. I create patch to fix it. With this
patch i can get static library. This patch is very raw.

Submitted: Ivan Romanov (ivanromanov) - 2010-12-16 23:29:19 UTC
2010-12-18 19:29:24 -02:00
Marcelo Roberto Jimenez
c21a67f2d1 Doxygen, reformating, compiler warnings. 2010-11-21 21:40:07 -02:00
Stefan Sommerfeld
243cd41974 Fix for inline usage. 2010-11-07 18:31:48 -02:00
Stefan Sommerfeld
4b47e6a51d Fix for mixed usage of SOCKET and int. 2010-11-07 17:52:14 -02:00
Carl Benson
8e846368e0 patch for taking notice of UPNP_USE_RWLOCK flag in threadutil
By "Carl Benson" <carl.benson@windriver.com>:

I had to do some modifications myself though, because the Android
build system insists on having a file named "util.h" taking precedence
in its include path, libupnp gets confused because of the same filename
in upnp/src/inc/util.h
2010-11-01 01:06:11 -02:00
Marcelo Roberto Jimenez
cc472bc2cd Doxygen and indentation for sock. 2010-10-20 09:05:42 -02:00
Marcelo Roberto Jimenez
8401a59ed5 New function, sock_close(). 2010-10-15 12:25:35 -03:00
Marcelo Roberto Jimenez
2bcbdffd89 1 - Ported some of IPV6 code to 1.6.7.
2 - Backport of svn revision 527:
* Added API to ithread, created the following functions:
- int ithread_initialize_library(void);
- int ithread_cleanup_library(void);
- int ithread_initialize_thread(void);
- int ithread_cleanup_thread(void);
* SF Bug Tracker [ 2876374 ] Access Violation when compiling with Visual Studio 2008
Submitted: Stulle ( stulleamgym ) - 2009-10-10 19:05

Hi,

I am one of the devs of the MorphXT project and I use this lib in some
other of my projects, too. When I tried to upgrade the lib earlier for one
of my projects I had to realise that something did not work at first and
while most of the things were reasonably ease to be fixed. Now, the last
thing I encountered was not so easy to fix and I am uncertain if my fix is
any good so I'll just post it here and wait for some comments.

The problem was that I got an Access Violation when calling "UpnpInit". It
would call "ithread_rwlock_init(&GlobalHndRWLock, NULL)" which eventually
led to calling "pthread_cond_init" and I got the error notice at
"EnterCriticalSection (&ptw32_cond_list_lock);". It appeared that
"ptw32_cond_list_lock" was NULL. Now, I found two ways to fix this. Firstly
moving the whole block after at least one of the "ThreadPoolInit" calls
will fix the issue. Secondly, you could add:
#ifdef WIN32
#ifdef PTW32_STATIC_LIB
// to get the following working we need this... is it a good patch or
not... I do not know!
pthread_win32_process_attach_np();
#endif
#endif
right before "ithread_rwlock_init(&GlobalHndRWLock, NULL)".

Just so you know, I am using libupnp 1.6.6 and libpthreads 2.8.0 and both
are linked static into the binaries. I am currently using Visual Studio
2008 for development with Windows being the target OS. Any comment at your
end?

Regards, Stulle



git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@529 119443c7-1b9e-41f8-b6fc-b9c35fce742c
2010-03-31 17:53:16 +00:00
Marcelo Roberto Jimenez
89e7a40fcc Removing unnecessary additional directory level.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@29 119443c7-1b9e-41f8-b6fc-b9c35fce742c
2006-07-04 02:44:17 +00:00