[parisc-linux] HP-UX application support?

[parisc-linux] HP-UX application support?

[MEYER,ALAN C. (HP-FtCollins,ex1)]

I have heard several descriptions of what will be supported for HP-UX
applications on 64-bit PA/Linux.

Can someone plz clarify what will be supported:
* 64-bit/ELF HP-UX applications
* 32-bit/SOM HP-UX applications

And, what about the install location of HP-UX shlibs required for these
64-bit (and 32-bit?) HP-UX applications?

Also, I am assuming the install model will be to simply copy files from an
HP-UX system over to a PA/Linux system.  In particular, I have heard of no
plans to support HP-UX packages bundled in "SD" format.  Right?

Thanks, Alan

Re: [parisc-linux] HP-UX application support?

[willy]

On Mon, Feb 28, 2000 at 02:14:17PM -0700, MEYER,ALAN C. HP-FtCollins,ex1" wrote:
> I have heard several descriptions of what will be supported for HP-UX
> applications on 64-bit PA/Linux.
> 
> Can someone plz clarify what will be supported:
> * 64-bit/ELF HP-UX applications
> * 32-bit/SOM HP-UX applications

We intend to support both of the above; in addition we also intend to
support 32 bit ELF Linux applications and, eventually, 64 bit ELF Linux
applications.  In case anyone didn't realise it, the current executables
we use are 32-bit SOM HP-UX applications.  Admittedly, the current sash
we have implements `-mount' by calling a linux syscall, but that's only
one command.

Not every application will work, but the vast majority of them will.
Binary support for threaded applications is most unlikely.

> And, what about the install location of HP-UX shlibs required for these
> 64-bit (and 32-bit?) HP-UX applications?

If we use a dynamically linked application, they would need to be placed
in the same location that HP/UX requires them to be.

> Also, I am assuming the install model will be to simply copy files from an
> HP-UX system over to a PA/Linux system.  In particular, I have heard of no
> plans to support HP-UX packages bundled in "SD" format.  Right?

Hmmm.. this is really a userspace problem that we haven't thought
about yet.  I anticipate that the `swinstall' program will work without
much pain and therefore installing .depot files will work.  However,
it wouldn't be the recommended way; packaging products as rpm or dpkg
(depending which distribution we pick) would be the preferred way to go.
There is a program called `alien' which can install other package formats,
extending that to support .depot files might be a fun thing to do for
someone with too much time on their hands :-)

Re: [parisc-linux] HP-UX application support?

[Philipp Rumpf]

> > And, what about the install location of HP-UX shlibs required for these
> > 64-bit (and 32-bit?) HP-UX applications?
> 
> If we use a dynamically linked application, they would need to be placed
> in the same location that HP/UX requires them to be.

We might want to look at the gnemul hack sparc did (include/asm-sparc/namei.h)
- ask the sparc people for their experiences with it first though.

RE: [parisc-linux] HP-UX application support?

[FINK,MARTIN (HP-FtCollins,ex1)]

> On Mon, Feb 28, 2000 at 02:14:17PM -0700, MEYER,ALAN C. 
> HP-FtCollins,ex1" wrote:
> > I have heard several descriptions of what will be supported 
> for HP-UX
> > applications on 64-bit PA/Linux.
> > 
> > Can someone plz clarify what will be supported:
> > * 64-bit/ELF HP-UX applications
> > * 32-bit/SOM HP-UX applications
> 
> We intend to support both of the above; in addition we also intend to
> support 32 bit ELF Linux applications and, eventually, 64 bit 
> ELF Linux
> applications.  In case anyone didn't realise it, the current 
> executables

I assume you're referring to 32-bit and 64-bit Intel Linux apps 
recompiled for PA/Linux?

Martin

Re: [parisc-linux] HP-UX application support?

[Grant Grundler]

willy@thepuffingroup.com wrote:

> > And, what about the install location of HP-UX shlibs required for these
> > 64-bit (and 32-bit?) HP-UX applications?
> 
> If we use a dynamically linked application, they would need to be placed
> in the same location that HP/UX requires them to be.

On HP-UX "SHLIB_PATH" envirment variables helps the dynamic linker
find shared libaries. Something equivalent for linux?

> However,
> it wouldn't be the recommended way; packaging products as rpm or dpkg
> (depending which distribution we pick) would be the preferred way to go.

If we can make .depot installs work, we could pull alot of stuff
from the porting center for starters. And it would also allow folks
to publish binaries for both OS's in a common format. That might not
be interesting to "real" linux hackers. But to folks using HP-UX, it
would make the transition to linux easier.

grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

Re: [parisc-linux] HP-UX application support?

[willy]

On Mon, Feb 28, 2000 at 02:47:45PM -0800, FINK,MARTIN HP-FtCollins,ex1" wrote:
> > On Mon, Feb 28, 2000 at 02:14:17PM -0700, MEYER,ALAN C. 
> > HP-FtCollins,ex1" wrote:
> > > I have heard several descriptions of what will be supported 
> > for HP-UX
> > > applications on 64-bit PA/Linux.
> > > 
> > > Can someone plz clarify what will be supported:
> > > * 64-bit/ELF HP-UX applications
> > > * 32-bit/SOM HP-UX applications
> > 
> > We intend to support both of the above; in addition we also intend to
> > support 32 bit ELF Linux applications and, eventually, 64 bit 
> > ELF Linux
> > applications.  In case anyone didn't realise it, the current 
> > executables
> 
> I assume you're referring to 32-bit and 64-bit Intel Linux apps 
> recompiled for PA/Linux?

I'm referring to applications which are written to the Linux APIs compiled
for either 32 or 64 bit PARISC/Linux/ELF.  I'm reluctant to describe
them as `Intel Linux apps', since they probably run on many other CPU /
OS combinations.  GNOME would be a great example here since it can be
built for many different platforms (including HP/UX, I believe), but most
of its users are probably on the IA32 + Linux platform.  There should
be no substantial differences between the user API between Linux running
on different CPUs.

Pedantry aside, the answer to the question you asked is, `Yes'  :-)

Re: [parisc-linux] HP-UX application support?

[willy]

On Mon, Feb 28, 2000 at 02:55:49PM -0800, Grant Grundler wrote:
> willy@thepuffingroup.com wrote:
> 
> > > And, what about the install location of HP-UX shlibs required for these
> > > 64-bit (and 32-bit?) HP-UX applications?
> > 
> > If we use a dynamically linked application, they would need to be placed
> > in the same location that HP/UX requires them to be.
> 
> On HP-UX "SHLIB_PATH" envirment variables helps the dynamic linker
> find shared libaries. Something equivalent for linux?

We would also use the HP/UX dynamic linker --- I don't want to write
a dynamic SOM linker.  The Linux ld.so uses LD_LIBRARY_PATH (and some
other interesting things -- man 8 ld.so for more details).

> > However,
> > it wouldn't be the recommended way; packaging products as rpm or dpkg
> > (depending which distribution we pick) would be the preferred way to go.
> 
> If we can make .depot installs work, we could pull alot of stuff
> from the porting center for starters. And it would also allow folks
> to publish binaries for both OS's in a common format. That might not
> be interesting to "real" linux hackers. But to folks using HP-UX, it
> would make the transition to linux easier.

I'm not against it, I'm just not terribly excited about it.  I don't know
much about packaging formats and issues people have there.  I guess that
having alien understand depot files is the right approach, but I really
don't know.

RE: [parisc-linux] HP-UX application support?

[MEYER,ALAN C. (HP-FtCollins,ex1)]

> > Can someone plz clarify what will be supported:
> > * 64-bit/ELF HP-UX applications
> > * 32-bit/SOM HP-UX applications
> 
> We intend to support both of the above; in addition we also intend to
> support 32 bit ELF Linux applications and, eventually, 64 bit 
> ELF Linux applications.  In case anyone didn't realise it, the
> current executables we use are 32-bit SOM HP-UX applications.
> Admittedly, the current sash we have implements `-mount' by
> calling a linux syscall, but that's only one command.

Yeah, I have loosely followed the interesting path taken with the toolchain
to get, eventually, to 64-bit ELF Linux apps.  But, there could be a
difference between what had to be done during development vs. wanting to
support it.  From HP's view, of course, supporting 32-bit SOM HP-UX apps is
great.

On a related note, is there any intention to support development of HP-UX
applications on PA/Linux?  Sure, a gcc cross-compiler could be created for
this.  But, my assumption is that PA/Linux would be a deployment environment
for HP-UX, but NOT a development environment.

> > And, what about the install location of HP-UX shlibs 
> > required for these 64-bit (and 32-bit?) HP-UX applications?
> 
> If we use a dynamically linked application, they would need 
> to be placed in the same location that HP/UX requires them to be.

Yes.  But, it gets stranger than that.  This topic has received lots of
airtime for IA-64 Linux, where x86 Linux apps will be supported.  The
existance of the IA-64 ABI "mandates" some of the rules for that platform,
but there are still some points that could apply here.

Actually, most of the HP-UX application issues should be OK because ... name
and version conflicts for shlibs are not so likely given the different
naming conventions for HP-UX (.sl) and Linux (.so).  This gets rid of many
of the issues IA-64 is dealing with - although /lib and /usr/lib may get
heavily populated.

BTW, you could imagine someone wanting to run both 32- and 64-bit HP-UX
apps.  The convention used by HP-UX shlibs seems to be:

	/usr/lib/libm.sl
	/usr/lib/pa20_64/libm.sl

But, the real problems will arise when supporting both 32- and 64-bit Linux
apps on PA.  I assume you meant that both 32- and 64-bit Linux apps would be
supported on 64-bit PA/Linux.  If not, never mind!  If so, this creates some
fun issues, such as:

* There will be naming conflicts between the 32- and 64-bit shlibs (and for
config files, man pages, etc.).  The RPMs for both the 32- and 64-bit
package will want to install in the same locations.

How to address?  Could create subdirs, such as /lib/32bit/... for the 32-bit
libs.  By mucking with rpm and the Linux loader, this could be addressed OK.
But, still a problem for config files and such.

Have I missed the mark, or aren't there some lurking issues here?

Alan

Re: [parisc-linux] HP-UX application support?

[Steven Pritchard]

MEYER,ALAN C. \(HP-FtCollins,ex1\) said:
> Also, I am assuming the install model will be to simply copy files from an
> HP-UX system over to a PA/Linux system.  In particular, I have heard of no
> plans to support HP-UX packages bundled in "SD" format.  Right?

The SD depot files are just tar files.  Supporting them would be
trivial.  You can always untar it, move everything to the appropriate
location, and run the scripts.  Making that automated (maybe with
alien) probably wouldn't be at all difficult...

Steve
-- 
steve@silug.org           | Linux Users of Central Illinois
(618)398-7320             | Meetings the 4th Tuesday of every month
Steven Pritchard          | http://www.luci.org/ for more info

Re: [parisc-linux] HP-UX application support?

[Corne Beerse]

Steven Pritchard wrote:
> MEYER,ALAN C. \(HP-FtCollins,ex1\) said:
> > Also, I am assuming the install model will be to simply copy files from an
> > HP-UX system over to a PA/Linux system.  In particular, I have heard of no
> > plans to support HP-UX packages bundled in "SD" format.  Right?
> 
> The SD depot files are just tar files.  Supporting them would be
> trivial.  You can always untar it, move everything to the appropriate
> location, and run the scripts.  Making that automated (maybe with
> alien) probably wouldn't be at all difficult...

It's verry easy to hack something yourself: untar the file and have a look
at directories you don't think they belong to the tool. Have a look, they
are scripts and textfiles which contain information what to do. It is verry
easy to write a script (if you need it) for installation. The only question
is if your script is complete. The origional should run in GOD mode (root)
so yours must do so if other users need to use the commands you install.

CB

-- 
Everything should be as simple as possible but not simpler - A. Einstein
Corne' Beerse					| Alcatel Telecom Nederland
mailto:beerse@ats.nld.alcatel.nl		| Postbus 3292
talkto:+31(70)3079108 faxto:+31(70)3079191	| NL-2280 GG  Rijswijk