RE: [Devel] HPUX 10.0 compile of freetype and Jam

[David Smith]

Thank you for the response.
I am continuing to look into why the version 6 versus version 8 gets generated. 
I have found (in the libtool code)
where the internal name (on both Solaris and HPUX) and the forced use of a 
fixed directory are located. These options make sense when the library is 
shipped as part of the OS or as a fixed attachment. I have modified things so 
that neither of them are done on Solaris and HPUX and everything works fine. 
Clearly not something you want to do with a normal FreeType distribution.

Once I have made the changes above the library version number is meaningless 
(since it is no longer enforced). It is just a curiosity as to why it is 
different on HP and the other systems I am build on (HP, IBM, Solaris, and 
Redhat Linux).

Thanks again for the response and if I find something interesting or relevant 
on why the 8 is generated I will let you know.

Regards
David

PS - I know that the real issue is not a freetype one but is an artifact of 
libtool.

-----Original Message-----
From: Werner LEMBERG [mailto:address@hidden
Sent: Tuesday, January 15, 2002 4:21 PM
To: address@hidden; address@hidden
Subject: Re: [Devel] HPUX 10.0 compile of freetype and Jam



> When I build the freetype library using make I get the behavior that
  the sl is version 8 (instead of version 6) (thank you libtool) which
  causes other problems for me (such as the name being forced as an
  internal name, the path being forced, librarys is shared but
  statically loaded, etc...).  What I am trying to do is build a
  shared, dynamic load library with the same name on all platforms.
  This is then being used as part of a CAD system for font handling.
  Works find on AIX, Solaris, Linux, Windows NT.  Not so good on
  HPUX 10.

> I can go and modify the way the sl is built by going around libtool
  but would appreciate some incite into why libtool does what it is
  doing (in terms of name, forcing an internal name, +b enabled
  forcing a fixed location on install, +s disabled so that SH_LIBPATH
  does not work, why the library is shared but statically linked,
  etc...).

I believe this is beyond our knowledge.  The probably best solution is
to contact the libtool team <address@hidden>, informing us how to fix
your problem.


    Werner