Reference:
http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html
Re: automake 1.12 and AM_PROG_AR
From: Nick Bowler
Subject: Re: automake 1.12 and AM_PROG_AR
Date: Thu, 10 May 2012 17:16:04 -0400
User-agent: Mutt/1.5.21 (2010-09-15)
On 2012-05-10 12:52 +0200, Simon Josefsson wrote:
> Hi,
>
> I have received patches similar to the one below for several of my
> projects already, and I'm beginning to think there may be something that
> could be improved in automake. Why does automake 1.12 need something
> that 1.11 doesn't even recognize? Perhaps a smoother way to introduce
> this behaviour is to let 1.12 automatically enable it?
>
> Alternatively, is there some other way to address the warnings that is
> better? Does it indicate a real problem in my projects?
>
> http://lists.gnu.org/archive/html/help-libidn/2012-05/msg00000.html
> http://lists.gnu.org/archive/html/help-libidn/2012-05/txtqAGOGgtPqj.txt
FYI, since the patch is so short it would have been helpful to include
it inline in your email. I've taken the liberty of reproducing it
below:
> --- libidn-1.24.orig/configure.ac
> +++ libidn-1.24/configure.ac
> @@ -34,6 +34,10 @@ AC_SUBST(LT_CURRENT, 17)
> AC_SUBST(LT_REVISION, 7)
> AC_SUBST(LT_AGE, 6)
>
> +# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it
> +m4_pattern_allow([AM_PROG_AR])
> +AM_PROG_AR
> +
> AC_PROG_CC
> gl_EARLY
> lgl_EARLY
First off, this patch seems wrong at a first glance by its use of
m4_pattern_allow: this is saying that "It's ok for AM_PROG_AR to appear
verbatim in the configure script". This suggests to me that the patch
didn't actually get tested (well) on Automake 1.11, since there will
almost certainly be an error about AM_PROG_AR at configure time.
This one should actually work properly on both old and new Automake
(untested):
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
That being said, the new warning is enabled by the -Wextra-portability
option that was added to Automake-1.12. I'm by no means an export on
this issue, but I think it relates to new support for building with the
Microsoft compiler: in other words, I think that ignoring this warning
will not cause regressions in your package but, instead, your package
will simply not be able to make use of the new feature.
Regardless, I believe that for most packages the new warning is actually
caused by Libtool, and therefore the correct place to add the call to
AM_PROG_AR is in libtool itself, rather than ad-hoc patching of each
package individually. You can silence the warnings (but not fix them)
by adding -Wno-extra-portability to AM_INIT_AUTOMAKE.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
(cherry picked from commit 3509991872)
Add --enable-unspecified_server configure option to set to "Unspecified"
the OS name, OS version, product name and product version normally
contained in the SERVER header as this could be used by an attacker.
(forward port of commit 49af91fe48)
Modify configure.ac to add --disable-optssdp option. This option will
remove OPT, 01-NLS and X_USER_AGENT headers from SSDP messages as those
headers are optional. If --disable-gena and disable-optssdp are both
used, uuid part will not be compiled anymore.
(cherry picked from commit 731512b0e5)
Currently, pupnp is using a blocking connect to sends GENA
notifications. As a result, when there is a lot of notifications with
CPs which were disconnected without unsusbcribing, all the pupnp
threads are blocked for 20s (timeout). To correct this issue, this
patch replace the call to connect with a call to private_connect and add
a compilation flag to disable blocking TCP connections, so if we are not
able to connect to the CP, the notification is lost.
(cherry picked from commit 32cffb5bb5)
SF Bug Tracker - ID: 3104521
Submitted: OBATA Akio ( obache ) - 2010-11-07 07:03:44 BRST
In configure.ac
AC_CHECK_FUNCS(ftime,, [AC_CHECK_LIB(compat, ftime)])
But since version 1.6.3, ftime(3) is not used, so it should be
removed, or introduce unwanted linkage with -lcompat.
(cherry picked from commit 852c301c5c)
Adding a configure flag to disable GENA notification reordering as even
with an imillisleep(1), this mechanism consumes too much CPU on embedded
devices when there is a burst of notifications.
(cherry picked from commit c73d870f46)
- 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/trunk@527 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Patch Tracker [ 2836704 ] Patch for Solaris10 compilation and usage.
Submitted By: zephyrus ( zephyrus00jp )
This second part covers the issue on linking with -lsocket -lnsl -lrt.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@526 119443c7-1b9e-41f8-b6fc-b9c35fce742c
The fact that we now have an active developer on branch ipv6 made me do this before I would like to.
The idea here is to hide libupnp internal data structures from the outside world so that
developers can be free to change them without breaking the interface. There is still some work to do
before a formal release, but the samples (device and control point) should be working.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@353 119443c7-1b9e-41f8-b6fc-b9c35fce742c
