Bug 236059

Summary: Port setuputil onto HP-UX
Product: [Retired] 389 Reporter: Noriko Hosoi <nhosoi>
Component: Install/UninstallAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0.4   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 17:18:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 152373, 240316, 427409    
Attachments:
Description Flags
cvs diff configure.ac Makefile.am autogen.sh
none
cvs diffs (derived files)
none
build-hp-setuputil.pl
none
cvs commit message none

Description Noriko Hosoi 2007-04-11 18:35:28 UTC
Description of problem:
This bug is a follow up of "234893: Build SetupUtil with autotools"

Comment 1 Noriko Hosoi 2007-04-13 20:23:19 UTC
Created attachment 152585 [details]
cvs diff configure.ac Makefile.am autogen.sh

Files: configure.ac Makefile.am autogen.sh

Changes:
configure.ac: Introduced --enable-64bit for HP (just adding -DHPUX_64 flag for
HP-UX)
Makefile.am: Added $(SASL_LINK) to the link command line for libdsinstall.so
autogen.sh: Upgraded automake version from 1.9.2 to 1.9.6, which is needed to
generate the proper link command line on HP-UX.  With 1.9.2, it generates
'$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
which is not appropriate to build a shared library from C++ code on HP.  1.9.6
has fixed the problem and it generates this link command:
'$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags'

Comment 2 Noriko Hosoi 2007-04-13 20:39:45 UTC
Created attachment 152586 [details]
cvs diffs (derived files)

Files:
 Makefile.in
 aclocal.m4
 compile
 config.guess
 config.sub
 configure
 depcomp
 install-sh
 missing

Comment 3 Noriko Hosoi 2007-04-13 20:53:31 UTC
Created attachment 152588 [details]
build-hp-setuputil.pl

Modified build-hp-ds.pl for SetupUtil.	build-hp-ds.pl was written by Nathan
for DS.

Usage:
./build-hp-setuputil.pl
	-t <path>      Path to the source tree
	-i <path>      Absolute path to installation directory
	-z	       Create optional tarball package
	-H	       Print this help message

Sample usage:
cd one level above "setuputil" dir.
./build-hp-setuputil.pl -t `pwd`/setuputil -i /path/to/install/setuputil
ln -s /path/to/install/setuputil/opt/setuputil /opt

Comment 4 Rich Megginson 2007-04-14 02:26:12 UTC
Looks good.

I think --enable-64bit should do a lot more, and we should use it on Solaris as
well.  But for now it's ok as it is.  In the future, I'd like to see the Solaris
and HP-UX builds just default to 64 bit, so that you would actually have to say
--disable-64bit to get a 32bit build on sparc or ipf.  We should also figure out
a way to set the CC, CFLAGS, etc. for 64bit.  But all of that stuff is future -
we'll have to change all of our configure.ac to do that.

Also, it's not necessary to attach the derived file diffs like Makefile.in.


Comment 5 Noriko Hosoi 2007-04-16 23:51:52 UTC
Created attachment 152728 [details]
cvs commit message

Reviewed by Rich (Thank you!!)

Checked in into HEAD.

Comment 6 Noriko Hosoi 2007-04-17 00:01:56 UTC
(In reply to comment #4)
> I think --enable-64bit should do a lot more, and we should use it on Solaris as
> well.  But for now it's ok as it is.  In the future, I'd like to see the Solaris
> and HP-UX builds just default to 64 bit, so that you would actually have to say
> --disable-64bit to get a 32bit build on sparc or ipf.  We should also figure out
> a way to set the CC, CFLAGS, etc. for 64bit.  But all of that stuff is future -
> we'll have to change all of our configure.ac to do that.

I also thought it'd be nice if we don't have to pass CC=aCC, etc. for
Solaris/HP-UX by default.  If the environment variables are set, they should be
used, but it'd be nice to have the platform/system specific default (instead of
gcc/g++).  I quickly tested, but the location where checking the platform in our
configure.ac is too late.  We have to check it very first, determine the
compilers and their flags, and check the other configurations...  Rich, I
verified your comment "we'll have to change all of our configure.ac to do that"
is correct. ;)


Comment 7 Nathan Kinder 2007-11-29 17:21:43 UTC
We no longer use setuputil.  It was ported to build on HP-UX however.  Marking
this as VERIFIED.