[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: teTeX on HURD (Was: My Hurd speaks PostScript)



On Sat, Nov 20, 1999 at 09:52:11AM +0530, Kapil H. Paranjape wrote:
>  > > It has a script called klibtool that pre-dates libtool.  I intend to
>  > > change it so that it calls libtool.
>  > 
>  > That's a good idea. Only the very latest libtool has the correct info for
>  > the Hurd.
> 
> I didn't incorporate libtool since:
> 	(a) I wanted to do the build with minimal changes.
> 		(sheer laziness ...)
>         (b) The klibtool script said it was a modification of the
>    	    libtool scripts so I didn't want to go into those modifs.
> 
> But I suppose I should have tried.

Not necessarily. It's a good idea to keep changes minimal by all means.
I too was too lazy to investigate the diff between klibtool and libtool,
maybe it's a trivia, maybe not. It only matters if the produced libraries
are incorrect.

>  > > There is also a call to a command line getopt.
> 
> I don't recall any problem here. Where is this call? In debian/rules?
> Or perhaps it is a call in "libtool" which I did not use.

We need more info from Chris then. I doubt it is used in libtools, as
libtool is GNU, and util-linux is not (which means such a dependency would
be found and fixed soon). But maybe I am wrong ...
 
>  > The klibtool/libtool issue is definitely worth investigation. Kapil,
>  > did your build produce the same sonames as a Linux build? That's important.
> 
> The library produced is libkpathsea.so.3.3.1 in both cases (linux and
> hurd). Is there a more complete way of checking? In any case I will
> investigate the possiblity of using klibtool.

Yes, please check 

$ objdump --private-header libkpathsea.so.3.3.1 |grep SONAME

it should be something like:
  SONAME      libkpathsea.so.3.3.1

> As far as I recall, the build completes without errors. The
> installation of tetex-extra invokes the difficulty with "double
> ungetc" commented on earlier in this list.

Okay, thanks. It seems that some of Chris problems were not reproduced by
you, and I tihnk Chris should carefully investigate what he did and if the
problems are because of his changes/local setup or because of the upstream
source.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de,     marcus@gnu.org    PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       brinkmd@debian.org


Reply to: