screen-devel
[Top][All Lists]
Advanced

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

Re: [screen-devel] [PATCH] Fixing configure script and removing LOTS of


From: Micah Cowan
Subject: Re: [screen-devel] [PATCH] Fixing configure script and removing LOTS of GCC warnings on HP-UX
Date: Tue, 11 Nov 2008 14:09:18 -0800
User-agent: Thunderbird 2.0.0.17 (X11/20080914)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gavrichenkov, Artyom wrote:
> Hi all,
> 
> While compiling GNU Screen sources on HP-UX operating system I faced two 
> issues:
> - configure script failed to locate termcap shared libraries;
> - GCC produced a batch of warnings about "incompatible implicit declaration" 
> of strlen and (less frequent) strcpy functions.
> 
> It's interesting for me that all these warnings seem to be intended -- 
> there's even special #ifdef to generate them, but for what reason? Maybe the 
> answer is changes in HP-UX system headers since "os.h" header has been 
> written, but I don't know exactly.
> 
> I'm providing a fix for all this. The following patch is tested on HP-UX on 
> both IA64 (OS v11.23) and PA-RISC (OS v11.11) architectures with GNU Screen 
> 4.0.3 and works good.
> 
> Artyom Gavrichenkov | Engineer, HP Global Delivery Russia Center | Mailto: 
> address@hidden | Tel. No: +7 916 515 4958
> 
> ---
> diff -Nurp screen-4.0.3/configure screen-4.0.3.hpux/configure
> --- screen-4.0.3/configure      2003-12-05 16:46:53.000000000 +0300
> +++ screen-4.0.3.hpux/configure 2008-11-11 22:16:48.000000000 +0300
> @@ -4789,6 +4789,9 @@ else
>  sed 's/^/| /' conftest.$ac_ext >&5
> 
>  LIBS="-ltermcap $olibs"
> +if [ `uname` = "HP-UX" ]; then
> +  LIBS="-L/usr/local/lib/hpux32 "$LIBS
> +fi
>  { echo "$as_me:$LINENO: checking libtermcap..." >&5
>  echo "$as_me: checking libtermcap..." >&6;}
>  cat >conftest.$ac_ext <<_ACEOF
> @@ -7945,6 +7948,9 @@ if test -z "$old_CFLAGS"; then
>    fi
>  fi
>  test -n "$seqptx" && LIBS="-ltermcap -lc -lsocket -linet -lnsl -lsec -lseq"
> +if [ `uname` = "HP-UX" ]; then
> +  LIBS="-L/usr/local/lib/hpux32 "$LIBS
> +fi
> 
>  if test "$cross_compiling" = yes; then
>    { { echo "$as_me:$LINENO: error: cannot run test program while cross 
> compiling
> diff -Nurp screen-4.0.3/os.h screen-4.0.3.hpux/os.h

On the HP-UX 11 system I'm looking at, libtermcap is under /usr/lib.

/usr/local is generally reserved for... _locally_ installed libraries.
It doesn't strike me as appropriate to hardcode some path from there
into our configure script. It seems more appropriate to me that you give
the configure script appropriate arguments; perhaps (untested):

  ./configure LIBS='-L/usr/local/lib/hpux32'

> --- screen-4.0.3/os.h   2002-01-08 18:42:33.000000000 +0300
> +++ screen-4.0.3.hpux/os.h      2008-11-11 22:18:00.000000000 +0300
> @@ -83,7 +83,7 @@ extern int errno;
>  #  define strlen ___strlen___
>  #  include <string.h>
>  #  undef strlen
> -#  if !defined(NEWSOS) && !defined(__hpux)
> +#  if !defined(NEWSOS)
>      extern size_t strlen(const char *);
>  #  endif
>  # else /* SVR4 */
> 

But this defines strlen to return the wrong type! (At least, the HP-UX
machine I have handy has strlen returning int.) That's presumably the
reason for the #if's; not to produce spurious warnings.

You could perhaps place an #else there to declare it properly returning
an int; I suspect a better solution would be to move the #undef so it
only fires in the body of that #if.

Better yet, perhaps we can remove that re-definition of strlen
altogether. Anyone around here know what it was there for? Must have
been some reason we throw out the system's idea of what strlen is...

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJGgKN7M8hyUobTrERAkzKAJ4yKbWrSEdTgZXiPGGhFzzRElRn8ACfcFer
WmAbNj7eju5yNR8hSDYP3v8=
=fz7G
-----END PGP SIGNATURE-----




reply via email to

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