Subject: Re: bug#35650: [PATCH] Improving HP-UX support

From: "Osipov, Michael" <[email-masked]>
Date: Tue, 14 May 2019 15:52:33 +0200

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