rsync - Dec 2009 - DO NOT REPLY [Bug 7015] New: Build problems on HP-UX, Tru64 -- alloca, -Wno-unused-parameter

https://bugzilla.samba.org/show_bug.cgi?id=7015

           Summary: Build problems on HP-UX, Tru64 -- alloca, -Wno-unused-
                    parameter
           Product: rsync
           Version: 3.0.6
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned at samba.org
        ReportedBy: sms at antinode.info
         QAContact: rsync-qa at samba.org


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".


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015


wayned at samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #1 from wayned at samba.org  2009-12-30 21:38 CST -------
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?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015





------- Comment #2 from wayned at samba.org  2009-12-30 22:07 CST -------
Actually, I think that my proposed "#else" needs to be this:

#elif !defined(alloca)

Otherwise I see some re-defined warnings under Linux.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015





------- Comment #3 from sms at antinode.info  2009-12-30 23:34 CST
-------
> #elif !defined(alloca)
   That seems to satisfy everyone here regarding alloca.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015





------- Comment #4 from carson at taltos.org  2009-12-31 15:43 CST -------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015


wayned at samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #5 from wayned at samba.org  2009-12-31 15:53 CST -------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015





------- Comment #6 from matt at mattmccutchen.net  2009-12-31 16:15 CST -------
(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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=7015





------- Comment #7 from sms at antinode.info  2010-01-02 18:08 CST -------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.