Bug 7015 - Build problems on HP-UX, Tru64 -- alloca, -Wno-unused-parameter
Summary: Build problems on HP-UX, Tru64 -- alloca, -Wno-unused-parameter
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.6
Hardware: Other Other
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-30 17:58 UTC by Steven M. Schweda
Modified: 2010-01-02 18:08 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steven M. Schweda 2009-12-30 17:58:17 UTC
Build problem with alloca()

Using GCC on Tru64 and HP-UX causes complaints like this (HP-UX shown):

        gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -Wno-unu
sed-parameter  -c popt/findme.c -o popt/findme.o
popt/findme.c: In function 'findProgramPath':
popt/findme.c:28: warning: implicit declaration of function 'alloca'
popt/findme.c:28: warning: incompatible implicit declaration of built-in functio
n 'alloca'

   Suggestion:

dyi # gdiff -u ./popt/system.h_orig ./popt/system.h
--- ./popt/system.h_orig        2006-11-08 20:37:38.000000000 -0600
+++ ./popt/system.h     2009-12-30 05:03:15.000000000 -0600
@@ -87,6 +87,8 @@
 # endif
 #elif defined(__GNUC__) && defined(__STRICT_ANSI__)
 #define alloca __builtin_alloca
+#elif HAVE_ALLOCA_H
+# include <alloca.h>
 #endif

 #ifndef HAVE_STRLCPY

   Rationale:

The use of GCC should not preclude the use of <alloca.h>.

I haven't looked at what happens with __STRICT_ANSI__ defined,
so even broader use of <alloca.h> may make more sense
("#if"+"#endif", instead of "#elif"?).


      Build problem with -Wno-unused-parameter

On Tru64 using DEC/Compaq/HP C, the "configure" test for the safety
of the -Wno-unused-parameter is too tolerant.  This compiler
apparently hates this option, but is willing to pass it along to
"ld", who doesn't like it either.  Thus, the compile-only test
in "configure.sh" looks successful, but the actual build fails:

urtx# gmake
[...]
ld: Invalid flag usage: Wno-unused-parameter, -Wx,-option must appear after -_SYSTYPE_SVR4
ld: Usage: ld [options] file [...]
Failed to create rounding.h!
gmake: *** [rounding.h] Error 1


   Versions:

Rsync 3.0.5, 3.0.6, 3.0.7pre2

dyi # uname -a
HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license
dyi # gcc --version
gcc (GCC) 4.3.3
[...]

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Mar 20 20:19:48 CDT 2009
urtx# cc -V
Compaq C V6.5-303 (dtk) on HP Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver


   The complaint form here seems to have no accommodation for
multiple platforms other than "All", so I chose "Other".
Comment 1 Wayne Davison 2009-12-30 21:38:34 UTC
In the alloca check of a modern configure script, it defines alloca to be __builtin_alloca even if __STRICT_ANSI__ is not defined.  Would changing the lines:

#elif defined(__GNUC__) && defined(__STRICT_ANSI__)
#define alloca __builtin_alloca

to be just:

#else
#define alloca __builtin_alloca

work for your system?
Comment 2 Wayne Davison 2009-12-30 22:07:30 UTC
Actually, I think that my proposed "#else" needs to be this:

#elif !defined(alloca)

Otherwise I see some re-defined warnings under Linux.
Comment 3 Steven M. Schweda 2009-12-30 23:34:14 UTC
> #elif !defined(alloca)

   That seems to satisfy everyone here regarding alloca.
Comment 4 Carson Gaspar 2009-12-31 15:43:00 UTC
Ummm... no. __builtin_alloca is a GCCism. Please do _not_ use it without wrapping it in a test for GCC.

For example, on Solaris, alloca may be an actual function, or a macro, depending on other compilation flags.
Comment 5 Wayne Davison 2009-12-31 15:53:37 UTC
The alloca define is already on the "else" side of a gcc test.

The test for -Wno-unused-parameter in configure now links a program, and doesn't use it if the program won't link successfully.
Comment 6 Matt McCutchen 2009-12-31 16:15:19 UTC
(In reply to comment #5)
> The alloca define is already on the "else" side of a gcc test.

That is, the "else" side of a /negated/ gcc test.  If/else with a negated condition is easy to misread.
Comment 7 Steven M. Schweda 2010-01-02 18:08:00 UTC
rsync-HEAD-20100102-1909GMT looks better on Tru64.  (Should be similarly
better on HP-UX.)  Thanks.

There are still a few warnings with GCC on Tru64.  I haven't looked
closely to see where to assign blame.  Let me know if a closer look is
justified.

urtx# gcc -v
Using built-in specs.
Target: alphaev6-dec-osf5.1b
Configured with: ../gcc-4.3.2/configure --enable-languages=c,c++,objc,obj-c++,tr
eelang
Thread model: posix
gcc version 4.3.2 (GCC)

[...]
gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -Wno-unused-para
meter  -c uidlist.c -o uidlist.o
uidlist.c: In function 'recv_add_id':
uidlist.c:210: warning: signed and unsigned type in conditional expression
uidlist.c:213: warning: signed and unsigned type in conditional expression
uidlist.c: In function 'match_uid':
uidlist.c:242: warning: comparison between signed and unsigned
uidlist.c: In function 'match_gid':
uidlist.c:257: warning: comparison between signed and unsigned
uidlist.c:261: warning: comparison between signed and unsigned
uidlist.c: In function 'add_uid':
uidlist.c:284: warning: comparison between signed and unsigned
uidlist.c: In function 'add_gid':
uidlist.c:302: warning: comparison between signed and unsigned
[...]


/usr/include/sys/types.h says:

[...]
#ifdef _XOPEN_SOURCE_EXTENDED
typedef int             uid_t;          /* user ID */
#else
typedef uint_t          uid_t;          /* user ID */
#endif
[...]
typedef uint_t          gid_t;          /* group ID */
[...]

So, I'd expect both to be uint_t.