GNU bug report logs -
#35650
[PATCH] Improving HP-UX support
Previous Next
To reply to this bug, email your comments to 35650 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Thu, 09 May 2019 14:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Osipov, Michael" <michael.osipov <at> siemens.com>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Thu, 09 May 2019 14:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi folks,
please find a patch attached to properly compile and link GNU coreutils
8.31 on HP-UX IA64. As of now, it does not compile out of the box.
The patch includes these changes:
* basenc.c: HP aCC does not allow anonymous unions inside structs, I
have named it otherwise the compilation fails
* blake2/blake2.h: __attribute__((packed)) does not exist in HP aCC, use
#pragma pack
* copy.c, mkfifo.c: disable SELinux code if it is not available
* system.h: use __attribute(x) on a GNU-style compiler only
* configure.ac, local.mk: use HP aCC-style linker options for libstdbuf
Compile instructions:
> export PREFIX=/opt/ports/coreutils
> export LIBDIR=$PREFIX/lib/hpux32
> export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
> export CPPFLAGS="-I$PREFIX/include -D_INCLUDE_STDC__SOURCE_199901"
> export LDFLAGS="-L$LIBDIR"
> autoreconf -fi
> FORCE_UNSAFE_CONFIGURE=1 gl_cv_have_include_next=no ac_cv_func_getacl=no ac_cv_func_aclsort=no ac_cv_header_sys_bitypes_h=no $CONFIGURE
> gmake install
The patch isn't perfect, some issues need to be discussion because I
don't know yet how to solve them:
* copy.c, mkfifo.c: for some reason the code compiles w/o changes
although SELinux is not available
* I have disabled the compilation of b2sum completely because gmake
repeatedly quits with:
> gmake[2]: *** No rule to make target '/var/tmp/AAA000546.i', needed by 'src/b2sum-md5sum.o'. Stop.
> gmake[2]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
> gmake[1]: *** [Makefile:12647: all-recursive] Error 1
> gmake[1]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
> gmake: *** [Makefile:6827: all] Error 2
* The configuration of PIC and shared library is for HP-UX now. At best
autotools would determine that with some default m4 file.
Note: I am not subscribed to this list.
Regards,
Michael
[coreutils.patch (text/plain, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Fri, 10 May 2019 09:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 35650 <at> debbugs.gnu.org (full text, mbox):
On 09/05/19 03:50, Osipov, Michael wrote:
> Hi folks,
>
> please find a patch attached to properly compile and link GNU coreutils
> 8.31 on HP-UX IA64. As of now, it does not compile out of the box.
>
> The patch includes these changes:
>
> * basenc.c: HP aCC does not allow anonymous unions inside structs, I
> have named it otherwise the compilation fails
> * blake2/blake2.h: __attribute__((packed)) does not exist in HP aCC, use
> #pragma pack
> * copy.c, mkfifo.c: disable SELinux code if it is not available
> * system.h: use __attribute(x) on a GNU-style compiler only
> * configure.ac, local.mk: use HP aCC-style linker options for libstdbuf
>
> Compile instructions:
>> export PREFIX=/opt/ports/coreutils
>> export LIBDIR=$PREFIX/lib/hpux32
>> export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
>> export CPPFLAGS="-I$PREFIX/include -D_INCLUDE_STDC__SOURCE_199901"
>> export LDFLAGS="-L$LIBDIR"
>> autoreconf -fi
>> FORCE_UNSAFE_CONFIGURE=1 gl_cv_have_include_next=no ac_cv_func_getacl=no ac_cv_func_aclsort=no ac_cv_header_sys_bitypes_h=no $CONFIGURE
>> gmake install
> The patch isn't perfect, some issues need to be discussion because I
> don't know yet how to solve them:
> * copy.c, mkfifo.c: for some reason the code compiles w/o changes
> although SELinux is not available
These selinux interfaces are provided by gnulib,
and so should automatically by ignored on HPUX.
I.E. I'm not sure this part is needed at all.
> * I have disabled the compilation of b2sum completely because gmake
> repeatedly quits with:
>> gmake[2]: *** No rule to make target '/var/tmp/AAA000546.i', needed by 'src/b2sum-md5sum.o'. Stop.
>> gmake[2]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
>> gmake[1]: *** [Makefile:12647: all-recursive] Error 1
>> gmake[1]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
>> gmake: *** [Makefile:6827: all] Error 2
> diff -ur src/blake2/blake2.h src/blake2/blake2.h
> --- src/blake2/blake2.h 2018-05-14 06:20:24 +0000
> +++ src/blake2/blake2.h 2019-05-08 15:08:42 +0000
> @@ -21,8 +21,12 @@
> #if defined(_MSC_VER)
> #define BLAKE2_PACKED(x) __pragma(pack(push, 1)) x __pragma(pack(pop))
> #else
> +#ifdef __hpux
> +#define BLAKE2_PACKED(x) x
>
> +#else
> #define BLAKE2_PACKED(x) x __attribute__((packed))
> #endif
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
> @@ -86,6 +90,9 @@
> size_t outlen;
> } blake2bp_state;
>
> +#ifdef __hpux
> +#pragma pack 1
> +#endif
>
> BLAKE2_PACKED(struct blake2s_param__
> {
> @@ -102,9 +109,15 @@
> uint8_t salt[BLAKE2S_SALTBYTES]; /* 24 */
> uint8_t personal[BLAKE2S_PERSONALBYTES]; /* 32 */
> });
> +#ifdef __hpux
> +#pragma pack
> +#endif
That's a bit awkward,
also this file comes from blake2 upstream source on github,
so you might want to broach the change there.
> diff -ur src/system.h src/system.h
> --- src/system.h 2019-01-05 11:36:22 +0000
> +++ src/system.h 2019-05-08 15:19:29 +0000
> @@ -422,6 +422,10 @@
> # endif
> #endif
>
> +#ifndef __GNUC__
> +#define __attribute(x) /* empty */
> +#endif
The only use of __attribute is:
src/libstdbuf.c:/* Use __attribute to avoid elision of __attribute__ on SUNPRO_C etc. */
src/libstdbuf.c:static void __attribute ((constructor))
So we should probably have special __hpux handling in that file
rather than doing the above.
This is all dependent on stdbuf actually working on your platform.
Possibly the most appropriate change would be to use __attribute
rather than __attribute__ in configure.ac
> #ifndef ATTRIBUTE_NORETURN
> # define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__))
> #endif
> --- configure.ac 2019-03-04 08:40:55 +0000
> +++ configure.ac 2019-05-08 15:40:41 +0000
> @@ -481,8 +481,8 @@
> gl_WARN_ADD([-errwarn], [CFLAGS])
> # Put this message here, after gl_WARN_ADD's chatter.
> AC_MSG_CHECKING([whether this system supports stdbuf])
> -CFLAGS="-fPIC $CFLAGS"
> -LDFLAGS="-shared $LDFLAGS"
> +CFLAGS="+z $CFLAGS"
> +LDFLAGS="-b $LDFLAGS"
This would need to be conditional,
again if stdbuf does actually work on hpux.
thanks,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Sat, 11 May 2019 21:16:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 35650 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for the bug report. I installed the attached patches to coreutils
on savannah to fix some (but not all) of the bugs, and some other
C99-related bugs I noticed, and have some further comments and questions.
On 5/9/19 5:50 AM, Osipov, Michael wrote:
>
> * basenc.c: HP aCC does not allow anonymous unions inside structs,
Fixed in the 3rd attached patch, in a slightly-different way.
> * blake2/blake2.h: __attribute__((packed)) does not exist in HP aCC,
> use #pragma pack
As near as I can make out, that code (a) doesn't need the packed
attribute on any popular platform, and (b) wouldn't be portable among
Standard C platforms even if Standard C had the packed attribute. I'll
try to follow up with the BLAKE2 folks and CC: here.
> * copy.c, mkfifo.c: disable SELinux code if it is not available
As you noted, this patch isn't needed (the code builds without it) so
let's omit the patch.
>
> * system.h: use __attribute(x) on a GNU-style compiler only
> * configure.ac, local.mk: use HP aCC-style linker options for libstdbuf
I don't see why these patches are needed. 'configure' should arrange for
libstdbuf to be built only if you are using GCC. If libstdbuf is being
built when you use HP-UX aCC, that suggests there is a bug in
'configure.ac' and we should fix that bug rather than try to port
libstdbuf to HP-UX.
>
>> FORCE_UNSAFE_CONFIGURE=1 gl_cv_have_include_next=no
>> ac_cv_func_getacl=no ac_cv_func_aclsort=no
>> ac_cv_header_sys_bitypes_h=no $CONFIGURE
>> gmake install
Why do you need all those flags and why do you need to use gmake? Plain
'./configure; make' should work. The fact that you need those flags
suggests that there is a bug in configure.ac, and it'd be better to fix
the underlying bug than to try to paper around it (and possibly
introduce further bugs).
> * I have disabled the compilation of b2sum completely because gmake
> repeatedly quits with:
>> gmake[2]: *** No rule to make target '/var/tmp/AAA000546.i', needed
>> by 'src/b2sum-md5sum.o'. Stop.
>> gmake[2]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
>> gmake[1]: *** [Makefile:12647: all-recursive] Error 1
>> gmake[1]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
>> gmake: *** [Makefile:6827: all] Error 2
Presumably your top-level Makefile is messed up somehow. Please
investigate the rule for building b2sum that is in 'Makefile', and try
to figure out how it got corrupted. It might be a bug in the way
'configure' calls 'sed', or a bug in your 'sed' or 'awk' implementation.
> * The configuration of PIC and shared library is for HP-UX now. At
> best autotools would determine that with some default m4 file.
Plain './configure; make' should work and if it doesn't work we should
fix it. Normally it does not build shared libraries or try to use PIC;
although you can arrange for it to do so that is lower priority for us.
[0001-build-update-gnulib-submodule-to-latest.patch (text/x-patch, attachment)]
[0002-maint-adjust-to-recent-verify_true-removal.patch (text/x-patch, attachment)]
[0003-basenc-port-to-C99.patch (text/x-patch, attachment)]
[0004-cp-port-fiemap.h-to-C99.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Sat, 11 May 2019 21:46:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 35650 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 5/10/19 4:49 AM, Pádraig Brady wrote:
> this file comes from blake2 upstream source on github,
> so you might want to broach the change there.
I'll cc: this email to contact <at> blake2.net to let them know about the
problem (if you're just catching up you can see the thread at
<https://bugs.gnu.org/35650>).
We shouldn't simply push this problem upstream to the BLAKE2
maintainers, as the BLAKE2 code is now in coreutils and if it breaks a
build then it's our responsibility to fix it. So for now I installed the
attached patch into coreutils, which I hope works around the BLAKE2
code's problem.
The underlying problem is that the reference code's definition of the
BLAKE2_PACKED macro assumes that the compiler is compatible with either
GCC or with Microsoft's C compiler, and HP-UX aCC is neither. As far as
I can see, for blake2.h on typical current platforms, there is no need
to use __attribute__ ((oacked)) or the Microsoft equivalent because the
data structure is already packed well enough, so the attached patch
simply skips the attribute unless we know that it will work.
I also noticed that the BLAKE2 code is not portable code according to
either POSIX or to the C standard, since it assumes types like uint64_t
that both standards say are optional. If that's OK with the BLAKE2
maintainers then the attached patch should suffice, as it should be
"good enough" for most common platforms. If you want the code to be
portable, you'll need to arrange for it to pack and unpack by hand, at
least on platforms that don't support a packed attribute and/or don't
support types like uint64_t.
[0001-b2sum-port-to-HP-UX-C.txt (text/plain, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Tue, 14 May 2019 14:35:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Am 2019-05-10 um 11:49 schrieb Pádraig Brady:
> On 09/05/19 03:50, Osipov, Michael wrote:
>> diff -ur src/system.h src/system.h
>> --- src/system.h 2019-01-05 11:36:22 +0000
>> +++ src/system.h 2019-05-08 15:19:29 +0000
>> @@ -422,6 +422,10 @@
>> # endif
>> #endif
>>
>> +#ifndef __GNUC__
>> +#define __attribute(x) /* empty */
>> +#endif
>
> The only use of __attribute is:
>
> src/libstdbuf.c:/* Use __attribute to avoid elision of __attribute__ on SUNPRO_C etc. */
> src/libstdbuf.c:static void __attribute ((constructor))
>
> So we should probably have special __hpux handling in that file
> rather than doing the above.
>
> This is all dependent on stdbuf actually working on your platform.
> Possibly the most appropriate change would be to use __attribute
> rather than __attribute__ in configure.ac
>
>> #ifndef ATTRIBUTE_NORETURN
>> # define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__))
>> #endif
>> --- configure.ac 2019-03-04 08:40:55 +0000
>> +++ configure.ac 2019-05-08 15:40:41 +0000
>> @@ -481,8 +481,8 @@
>> gl_WARN_ADD([-errwarn], [CFLAGS])
>> # Put this message here, after gl_WARN_ADD's chatter.
>> AC_MSG_CHECKING([whether this system supports stdbuf])
>> -CFLAGS="-fPIC $CFLAGS"
>> -LDFLAGS="-shared $LDFLAGS"
>> +CFLAGS="+z $CFLAGS"
>> +LDFLAGS="-b $LDFLAGS"
>
> This would need to be conditional,
> again if stdbuf does actually work on hpux.
How try that out? I have it in place and we'll know it in an instant:
> $ ldd $(which stdbuf)
>
> /opt/ports/coreutils/bin/stdbuf:
> libc.so.1 => /usr/lib/hpux32/libc.so.1
> libdl.so.1 => /usr/lib/hpux32/libdl.so.1
> $ ldd /opt/ports/coreutils/libexec/coreutils/libstdbuf.so
>
> /opt/ports/coreutils/libexec/coreutils/libstdbuf.so:
Regards,
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Tue, 14 May 2019 14:35:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Hi Paul,
Am 2019-05-11 um 23:14 schrieb Paul Eggert:
> Thanks for the bug report. I installed the attached patches to coreutils
> on savannah to fix some (but not all) of the bugs, and some other
> C99-related bugs I noticed, and have some further comments and questions.
>>
>> * system.h: use __attribute(x) on a GNU-style compiler only
>> * configure.ac, local.mk: use HP aCC-style linker options for libstdbuf
>
> I don't see why these patches are needed. 'configure' should arrange for
> libstdbuf to be built only if you are using GCC. If libstdbuf is being
> built when you use HP-UX aCC, that suggests there is a bug in
> 'configure.ac' and we should fix that bug rather than try to port
> libstdbuf to HP-UX.
Here it is w/o the patch:
> checking whether this system supports stdbuf... yes
> configure:68555: checking whether this system supports stdbuf
> configure:68582: /opt/aCC/bin/aCC -AC99 -o conftest -fPIC -g -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -shared -L/opt/ports/cor
> aCC: warning 901: unknown option: `-fPIC': use +help for online documentation.
> aCC: warning 901: unknown option: `-hared': use +help for online documentation.
> aCC: warning 919: "-s" and "-g/-g0/-g1/-G/-p/+I" are mutually exclusive. "-s" option ignored
> configure:68582: $? = 0
> configure:68587: result: yes
aCC does not exit with non-zero, it just prints a warning. configure.ac
makes false assumptions here at the end. Personally, I don't need
stdbuf. If it really should only be compiled with GCC, you should test
for GCC only.
Drop the hunk for system.h if you think it is not necessary.
>>
>>> FORCE_UNSAFE_CONFIGURE=1 gl_cv_have_include_next=no
>>> ac_cv_func_getacl=no ac_cv_func_aclsort=no
>>> ac_cv_header_sys_bitypes_h=no $CONFIGURE
>>> gmake install
>
> Why do you need all those flags and why do you need to use gmake? Plain
> './configure; make' should work. The fact that you need those flags
> suggests that there is a bug in configure.ac, and it'd be better to fix
> the underlying bug than to try to paper around it (and possibly
> introduce further bugs).
I agree here, I will take on this in the next round of patches if you
don't mind. I wanted to avoid a huge patch in the first place.
>> * I have disabled the compilation of b2sum completely because gmake
>> repeatedly quits with:
>>> gmake[2]: *** No rule to make target '/var/tmp/AAA000546.i', needed
>>> by 'src/b2sum-md5sum.o'. Stop.
>>> gmake[2]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
>>> gmake[1]: *** [Makefile:12647: all-recursive] Error 1
>>> gmake[1]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
>>> gmake: *** [Makefile:6827: all] Error 2
>
> Presumably your top-level Makefile is messed up somehow. Please
> investigate the rule for building b2sum that is in 'Makefile', and try
> to figure out how it got corrupted. It might be a bug in the way
> 'configure' calls 'sed', or a bug in your 'sed' or 'awk' implementation.
Right now, it is a bit awkward. After a 'gmake clean' and 'configure'
it works again. I will leave it as-is for now and maybe have a look at
it later.
>> * The configuration of PIC and shared library is for HP-UX now. At
>> best autotools would determine that with some default m4 file.
> Plain './configure; make' should work and if it doesn't work we should
> fix it. Normally it does not build shared libraries or try to use PIC;
> although you can arrange for it to do so that is lower priority for us.
See above.
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Tue, 14 May 2019 16:27:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 35650 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 5/14/19 6:52 AM, Osipov, Michael wrote:
>
> aCC does not exit with non-zero, it just prints a warning.
OK, I installed the attached patch to try to fix this problem with
'configure'. Please give it a try. We may need some more patches to fix
the problems you evidently observed with #include_next, getacl, aclsort,
and sys/bitypes.h.
[0001-stdbuf-port-configure-time-checking-to-HP-UX-aCC.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Tue, 14 May 2019 21:17:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Am 2019-05-14 um 18:26 schrieb Paul Eggert:
> On 5/14/19 6:52 AM, Osipov, Michael wrote:
>>
>> aCC does not exit with non-zero, it just prints a warning.
>
> OK, I installed the attached patch to try to fix this problem with
> 'configure'. Please give it a try. We may need some more patches to fix
> the problems you evidently observed with #include_next, getacl, aclsort,
> and sys/bitypes.h.
>
So:
> checking whether C compiler handles -Werror... no
> checking whether C compiler handles -errwarn... no
> checking whether this system supports stdbuf... yes
in detail:
> configure:68484: checking whether C compiler handles -Werror
> configure:68503: /opt/aCC/bin/aCC -AC99 -o conftest -g -Werror -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
> aCC: error 1914: bad form for `-W' option
> configure:68503: $? = 1 > configure:68513: result: no> configure:68522: checking whether C
compiler handles -errwarn
> configure:68541: /opt/aCC/bin/aCC -AC99 -o conftest -g -errwarn -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
> ld: Entry symbol "rrwarn" not found
> Fatal error.
> configure:68541: $? = 1
> configure:68551: result: no
> configure:68559: checking whether this system supports stdbuf
> configure:68586: /opt/aCC/bin/aCC -AC99 -o conftest +z -g -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -b -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
> configure:68586: $? = 0
> configure:68591: result: yes
I do not really understand the purpose of the patch as it does not
really test for PIC/shared. This [1] is a viable approach I have taken
to make it work for linker style on HP-UX. I guess one could steal that
and reuse for -fPIC/+z.
[1] https://github.com/git/git/pull/608/files
WDYT?
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Wed, 15 May 2019 09:31:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 35650 <at> debbugs.gnu.org (full text, mbox):
let's examine #include_next first:
Am 2019-05-14 um 18:26 schrieb Paul Eggert:
> On 5/14/19 6:52 AM, Osipov, Michael wrote:
>>
>> aCC does not exit with non-zero, it just prints a warning.
>
> OK, I installed the attached patch to try to fix this problem with
> 'configure'. Please give it a try. We may need some more patches to fix
> the problems you evidently observed with #include_next, getacl, aclsort,
> and sys/bitypes.h.
>
configure.ac:
> configure:8765: checking whether the preprocessor supports include_next
> configure:8803: /opt/aCC/bin/aCC -AC99 -c -g
-I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901
-Iconftestd1b -Iconftestd2 conftest.c >&5
> configure:8803: $? = 0
> configure:8824: result: yes
result:
> CC src/b2sum-md5sum.o
> cpp: "./lib/stdlib.h", line 28: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/stdio.h", line 43: error 4052: Unknown preprocessing
directive.
> cpp: "/usr/include/sys/stdsyms.h", line 63: warning 2001:
Redefinition of macro _INCLUDE_STDC__SOURCE_199901.
> cpp: "./lib/stddef.h", line 55: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/sys/types.h", line 39: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/unistd.h", line 40: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/stdlib.h", line 28: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/time.h", line 41: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/sys/stat.h", line 47: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/sys/time.h", line 39: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/limits.h", line 27: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/time.h", line 35: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/string.h", line 41: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/errno.h", line 27: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/stdlib.h", line 36: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/fcntl.h", line 61: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/dirent.h", line 27: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/inttypes.h", line 41: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/stdint.h", line 77: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/inttypes.h", line 41: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/time.h", line 35: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/wchar.h", line 55: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/inttypes.h", line 61: error 4062: "This file assumes that
'int' has exactly 32 bits. Please report your platform and compiler to
<bug-gnulib <at> gnu.org>."
> cpp: "./lib/time.h", line 35: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/ctype.h", line 35: error 4052: Unknown preprocessing
directive.
> cpp: "./lib/locale.h", line 41: error 4052: Unknown preprocessing
directive.
> gmake[2]: *** [Makefile:12142: src/b2sum-md5sum.o] Error 1
> gmake[2]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31'
command in question:
> + /opt/aCC/bin/aCC -AC99 -I. -I./lib -include config.h
-DHASH_ALGO_BLAKE2=1 -Ilib -I./lib -Isrc -I./src
-I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -g -c -o
src/b2sum-md5sum.o src/md5sum.c +Maked
without the '-include':
> bash-5.0# /opt/aCC/bin/aCC -AC99 -I. -I./lib -DHASH_ALGO_BLAKE2=1
-Ilib -I./lib -Isrc -I./src -I/opt/ports/coreutils/include
-D_INCLUDE_STDC__SOURCE_199901 -g -c -o src/b2sum-md5sum.o src/md5sum.c
+Maked
> "./lib/timespec.h", line 98: warning #2174-D: expression has no effect
> assume (-1 <= a.tv_nsec && a.tv_nsec <= 2 * TIMESPEC_HZ);
> ^
>
> "./lib/timespec.h", line 99: warning #2174-D: expression has no effect
> assume (-1 <= b.tv_nsec && b.tv_nsec <= 2 * TIMESPEC_HZ);
> ^
According the manual [1] the compiler supports #include_next, but for
some strange reason it does not when -include is used. The funny thing
is -include isn't even in the manual.
> bash-5.0# aCC -include
> aCC: error 1909: `-include' option requires argument
This one comes from:
> @USE_XLC_INCLUDE_FALSE <at> src_b2sum_CPPFLAGS = -include config.h
I will inquire this with HPE because it looks fishy to me.
I don't know how to solve this differently for now, but to disable
include_next in configure.ac if the compiler is aCC.
Michael
[1] https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c05054285
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Wed, 15 May 2019 10:25:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 35650 <at> debbugs.gnu.org (full text, mbox):
getacl, aclsort:
Am 2019-05-14 um 18:26 schrieb Paul Eggert:
> On 5/14/19 6:52 AM, Osipov, Michael wrote:
>>
>> aCC does not exit with non-zero, it just prints a warning.
>
> OK, I installed the attached patch to try to fix this problem with
> 'configure'. Please give it a try. We may need some more patches to fix
> the problems you evidently observed with #include_next, getacl, aclsort,
> and sys/bitypes.h.
>
I checked acl.m4, headers in /usr/include/, manpages with errno as well
as the affected C files:
* configure properly detects everything
* the code compiles flawlessly
so both ac_cv_func_getacl=no ac_cv_func_aclsort=no can be dropped.
Note: I don't have ACLs explcitly in use on our servers.
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Wed, 15 May 2019 10:50:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 35650 <at> debbugs.gnu.org (full text, mbox):
sys/bitypes.h:
Am 2019-05-14 um 18:26 schrieb Paul Eggert:
> On 5/14/19 6:52 AM, Osipov, Michael wrote:
>>
>> aCC does not exit with non-zero, it just prints a warning.
>
> OK, I installed the attached patch to try to fix this problem with
> 'configure'. Please give it a try. We may need some more patches to fix
> the problems you evidently observed with #include_next, getacl, aclsort,
> and sys/bitypes.h.
>
After evaluation of /usr/include:
> $ ll /usr/include/sys/*types*
> -r--r--r-- 1 bin bin 443 2007-02-15 22:31 /usr/include/sys/cred_types.h
> -r--r--r-- 1 bin bin 853 2007-02-15 22:31 /usr/include/sys/kc_typespec.h
> -r--r--r-- 1 bin bin 566 2007-01-12 20:37 /usr/include/sys/kthread_types.h
> -r--r--r-- 1 bin bin 530 2007-01-12 20:37 /usr/include/sys/proc_types.h
> -r--r--r-- 1 bin bin 17226 2010-08-14 23:23 /usr/include/sys/types.h
> -r--r--r-- 1 bin bin 6290 2007-02-15 22:31 /usr/include/sys/_inttypes.h
> osipovmi <at> deblndw024v:/tmp/system-compile/gnu/m4-1.4.18/m4
> $ ll /usr/include/*types*
> -r--r--r-- 1 bin bin 1132 2016-02-29 09:59 /usr/include/aouttypes.h
> -r--r--r-- 1 bin bin 1711 2016-02-29 09:59 /usr/include/elftypes.h
> -r--r--r-- 1 bin bin 14188 2007-02-15 22:36 /usr/include/inttypes.h
> -r--r--r-- 1 bin bin 1828 2016-02-29 09:59 /usr/include/langtypes.h
> -r--r--r-- 1 bin bin 3277 2007-02-15 22:36 /usr/include/nl_types.h
the ac_cv_header_sys_bitypes_h=no is redundant because there is no such
header file. It would default to no anyway.
So we're down to #include_next and the linking/PIC issue.
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Wed, 15 May 2019 18:00:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 35650 <at> debbugs.gnu.org (full text, mbox):
On 5/14/19 2:15 PM, Osipov, Michael wrote:
>> configure:68559: checking whether this system supports stdbuf
>> configure:68586: /opt/aCC/bin/aCC -AC99 -o conftest +z -g
>> -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -b
>> -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
>> configure:68586: $? = 0
>> configure:68591: result: yes
>
> I do not really understand the purpose of the patch as it does not
> really test for PIC/shared.
The patch alters the 'configure' script so that it's pickier about
rejecting warnings from the compiler.
The 'configure' script should be testing for -fPIC and -shared. It
should have something like this.
$as_echo_n "checking whether this system supports stdbuf... " >&6; }
CFLAGS="-fPIC $CFLAGS"
LDFLAGS="-shared $LDFLAGS"
stdbuf_supported=no
# Note we only LINK here rather than RUN to support cross compilation
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
...
_ACEOF
if ac_fn_c_try_link "$LINENO"; then :
stdbuf_supported=yes
fi
So there should be an -fPIC and a -shared in the command line, but there
isn't in the diagnostics you mentioned. This is puzzling because the
diagnostic output you mentioned in <https://debbugs.gnu.org/35650#20>
did have -fPIC and -shared. So my guess is that somehow your 'configure'
script wasn't regenerated properly after you upgraded to my recent patch.
Please investigate why that is. I suggest looking into your updated
'configure' script to see whether it matches mine in this area. You can
also try putting the shell command 'set -x' into the 'configure' where
you want more debugging output.
Or, it might be easier for you to regenerate the source code from
scratch, by running this on a GNU/Linux platform:
git clone https://git.savannah.gnu.org/git/coreutils.git
cd coreutils
./bootstrap
./configure
make dist
and then unpacking and building the resulting tarball on HP-UX.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Wed, 15 May 2019 20:03:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 35650 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 5/15/19 2:30 AM, Osipov, Michael wrote:
>
> I don't know how to solve this differently for now, but to disable
> include_next in configure.ac if the compiler is aCC.
Better yet, let's stop using the -include option as it's not portable.
The -include option was used only to attempt to keep b2sum.c identical
with upstream, but we've already given up on that for other reasons, so
I installed the attached patches to fix this (the first patch drops
-include, the second patch lessens changes from upstream).
[0001-b2sum-port-to-HP-UX-aCC.patch (text/x-patch, attachment)]
[0002-b2sum-sync-better-with-upstream.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Thu, 16 May 2019 08:11:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Am 2019-05-15 um 19:59 schrieb Paul Eggert:
> On 5/14/19 2:15 PM, Osipov, Michael wrote:
>>> configure:68559: checking whether this system supports stdbuf
>>> configure:68586: /opt/aCC/bin/aCC -AC99 -o conftest +z -g
>>> -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -b
>>> -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
>>> configure:68586: $? = 0
>>> configure:68591: result: yes
>>
>> I do not really understand the purpose of the patch as it does not
>> really test for PIC/shared.
>
> The patch alters the 'configure' script so that it's pickier about
> rejecting warnings from the compiler.
>
> The 'configure' script should be testing for -fPIC and -shared. It
> should have something like this.
Purely my bad, apologies:
> configure:68484: checking whether C compiler handles -Werror
> configure:68503: /opt/aCC/bin/aCC -AC99 -o conftest -g -Werror -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
> aCC: error 1914: bad form for `-W' option
> configure:68503: $? = 1
> configure:68513: result: no
> configure:68522: checking whether C compiler handles -errwarn
> configure:68541: /opt/aCC/bin/aCC -AC99 -o conftest -g -errwarn -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
> ld: Entry symbol "rrwarn" not found
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This probably no the message you were striving for, but it serves the
purpose.
> Fatal error.
> configure:68541: $? = 1
> configure:68551: result: no
> configure:68559: checking whether this system supports stdbuf
> configure:68586: /opt/aCC/bin/aCC -AC99 -o conftest -fPIC -g -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -shared -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5
> aCC: warning 901: unknown option: `-fPIC': use +help for online documentation.
> aCC: warning 901: unknown option: `-hared': use +help for online documentation.
> aCC: warning 919: "-s" and "-g/-g0/-g1/-G/-p/+I" are mutually exclusive. "-s" option ignored
> configure:68586: $? = 0
> configure:68591: result: no
Is that what you have expected now?
stdbuf is still compiled and linked:
> bash-5.0# find . -name stdbuf
> ./src/stdbuf
> bash-5.0# ./src/stdbuf
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Thu, 16 May 2019 08:43:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Am 2019-05-15 um 22:02 schrieb Paul Eggert:
> On 5/15/19 2:30 AM, Osipov, Michael wrote:
>>
>> I don't know how to solve this differently for now, but to disable
>> include_next in configure.ac if the compiler is aCC.
>
> Better yet, let's stop using the -include option as it's not portable.
> The -include option was used only to attempt to keep b2sum.c identical
> with upstream, but we've already given up on that for other reasons, so
> I installed the attached patches to fix this (the first patch drops
> -include, the second patch lessens changes from upstream)
Patches applied, autoreconf -fi run, ran configure w/o override and this
is what I get now:
> + /opt/aCC/bin/aCC -AC99 -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -g -c -o src/blake2/b2sum-blake2b-ref.o src/blake2/blake2b-ref.c +Maked
> "./lib/unistd.h", line 627: error #2035: #error directive: "Please include
> config.h first."
> #error "Please include config.h first."
> ^
>
> "./lib/unistd.h", line 629: error #2077-D: this declaration has no storage
> class or type specifier
> _GL_INLINE_HEADER_BEGIN
> ^
>
> "./lib/unistd.h", line 741: error #2065: expected a ";"
> _GL_CXXALIAS_SYS (chdir, int, (const char *file) _GL_ARG_NONNULL ((1)));
> ^
>
> "./lib/unistd.h", line 2147: error #2077-D: this declaration has no storage
> class or type specifier
> _GL_INLINE_HEADER_END
> ^
>
> "./lib/stdlib.h", line 665: error #2065: expected a ";"
> _GL_CXXALIAS_SYS (calloc, void *, (size_t nmemb, size_t size));
> ^
>
> 5 errors detected in the compilation of "src/blake2/blake2b-ref.c".
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Thu, 16 May 2019 22:32:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 35650 <at> debbugs.gnu.org (full text, mbox):
On 5/16/19 1:09 AM, Osipov, Michael wrote:
>
> Is that what you have expected now?
Yes.
>
> stdbuf is still compiled and linked:
If it works, great; if not then I suppose we have more work to do.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Fri, 17 May 2019 15:01:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 35650 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 5/16/19 1:42 AM, Osipov, Michael wrote:
> + /opt/aCC/bin/aCC -AC99 -I. -I./lib -DHASH_ALGO_BLAKE2=1
> -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src
> -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -g -c -o
> src/blake2/b2sum-blake2b-ref.o src/blake2/blake2b-ref.c +Maked
> "./lib/unistd.h", line 627: error #2035: #error directive: "Please
> include
> config.h first."
Oh, I forgot to update blake2b-ref.c. I installed the attached further
patch; please give it a try.
[0001-b2sum-port-blake2b-ref.c-to-HP-UX-aCC.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Mon, 20 May 2019 07:57:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Am 2019-05-17 um 00:31 schrieb Paul Eggert:
> On 5/16/19 1:09 AM, Osipov, Michael wrote:
>> stdbuf is still compiled and linked:
>
> If it works, great; if not then I suppose we have more work to do.
I don't know how to test stdbuf to figure out whether it works as intended.
Michael
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#35650; Package
coreutils.
(Mon, 20 May 2019 09:00:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 35650 <at> debbugs.gnu.org (full text, mbox):
Am 2019-05-17 um 17:00 schrieb Paul Eggert:
> On 5/16/19 1:42 AM, Osipov, Michael wrote:
>> + /opt/aCC/bin/aCC -AC99 -I. -I./lib -DHASH_ALGO_BLAKE2=1
>> -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src
>> -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -g -c -o
>> src/blake2/b2sum-blake2b-ref.o src/blake2/blake2b-ref.c +Maked
>> "./lib/unistd.h", line 627: error #2035: #error directive: "Please
>> include
>> config.h first."
>
> Oh, I forgot to update blake2b-ref.c. I installed the attached further
> patch; please give it a try.
Deleted my work dir, untarred 8.31, applied diff betweeen v8.31 and
master, autoreconf, configure, gmake.
Looks good to me:
> bash-5.0# ldd ./src/b2sum
>
> ./src/b2sum:
> libc.so.1 => /usr/lib/hpux32/libc.so.1
> libdl.so.1 => /usr/lib/hpux32/libdl.so.1
> bash-5.0# file ./src/b2sum
> ./src/b2sum: ELF-32 executable object file - IA64
Thank you very much.
Compiling GNU coreutils on HP-UX is now a snap!
Michael
This bug report was last modified 5 years and 357 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.