GNU bug report logs - #35650
[PATCH] Improving HP-UX support

Previous Next

Full log

View this message in rfc822 format

From: "Osipov, Michael" <michael.osipov <at> siemens.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigBrady.com>, 35650 <at> debbugs.gnu.org
Subject: bug#35650: [PATCH] Improving HP-UX support
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.