183093 - Add "configure"-option to link libXp statically (e.g. libXp.a instead of libXp.so)

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, enhancement)

Description

[Roland Mainz]

Since AIX and HP-UX do not have a shared-library version of libXp in all
releases but want to use Xprint in all their OS releases there should be a
general-purpose flag to enable use of a static version of the library instead
(until all OSes have been updated or EOL'ed... :) ...

Comment 1

[hacker formerly known as [e-mail]]

Ugh. Yet another configure option?  Are the versions of the OS that have the
shared lib even compatible with the versions that don't?  Or is this something
that could be easily worked around by downloading the shared lib for that
particular OS?

Comment 2

[Roland Mainz]

Christopher Seawood wrote:
> Ugh. Yet another configure option?  Are the versions of the OS that have the
> shared lib even compatible with the versions that don't? 

That depends on the version of X11 being used. AFAIK there are no problems
unless people start to mix major X11 releases (e.g. X11R5.x vs. X11R6.x), but
minor release differences should not hurt (correct me if I am wrong :)

> Or is this something
> that could be easily worked around by downloading the shared lib for that
> particular OS?

That part can only answered by the people who maintain the single platforms,
e.g. [e-mail] for AIX and [e-mail] for HP-UX.

The only requirement for Mozilla's Xprint module is libXp. In theory we could
simply import that code (~90kb of source code, mainly comments... :) into the
tree and use that code if libXp.so is not present at build time - but I guess
that is not an option, right (I could provide the patch for that - but that
would mean that we import code with the "MIT" license into the tree (in theory
this won't matter since there is other code with that license in mozilla/, too))
?

Comment 3

[Jim Dunn]

For HP... HP10.20 doesn't have it and so I --disable-xprint when
building.  HP11.00 has it and is built against libXp (I have never
tested or verified that it works however).

I am not sure what linking it statically would do... Why not something
like freetype where we check to see if the component is there and
load it conditionally at runtime?

Comment 4

[Mary Hoetzel]

For AIX: The same libXp.a works for AIX 4.3.3 and AIX 5 which are the OS
versions to be considered. libXp.a is shipped with AIX 5.2. It is not part of
AIX 5.1 or AIX 4.3.3. You can take libXp.a from an AIX 5.2 system and use it on
AIX 4.3.3 or 5.1 which is what we are doing.

  

Comment 5

[hacker formerly known as [e-mail]]

There's another complication that I mentioned to Roland on IRC.  The static
system libs generally aren't built with PIC.  It doesn't sound like the AIX
linker is picky about this particular issue but there are other platforms
(Solaris, I think) where linking non-PIC code into a shared library has caused
problems (bug 35419). That was one of the reasons we got rid of the
--with-static-<toolkit> options.

Importing the libXp code, IMO, is not an option.

Since it sounds like IBM already has a workaround and hpux support appears to be
fading (if not completely gone), marking wontfix.