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/)
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.
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.
Submitted: Nick Leverton ( leveret ) - 2010-04-19 07:44:10 PDT
Details: The recent codebase merge has removed a significant API call
which is used by several pupnp devices such as mediatomb and gmediaserver.
UpnpSetVirtualDirCallbacks() has been replaced by individual routines to
set each callback. Essentially this means that 1.6.7 will in fact be a majo
bump and 1.6.6 devices can no longer link against it. Could we have the call
reinstated please, perhaps as a wrapper around the individual calls ? As
it is, all distros will have to patch their 1.6.x apps, rebuild and re-link them.
The other removed API calls and external variables don't seem to be used
by any of the apps I have copies of, but UpnpSetVirtualDirCallbacks is
important for maintaining compatibility within 1.6.x.
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.
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.
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.
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
