Bug#3067: broken libXaw3d
>
> > > Package: xaw3d
> > > Version: 1.2a-3
> > > Debian: 1.1
> > >
> > > The symbolic link created in the /usr/X11R6/lib directory points, not
> > > into the Xaw3d directory, but to the local one.
> > yes, that's what we want: /usr/X11R6/lib/libXaw.so points
> > to /usr/X11R6/lib/libXaw.so.6.0, but look at the output
> > of "ldd /usr/X11R6/bin/xfig", or whatever, before you report
> > bugs (also check /etc/ld.so.conf, and observe the order carefully).
>
> Argh! No, it's the Xaw_3D_, not Xaw -- Xaw is fine. (Sorry felt a
> little patronised there for a sec. :)
>
> > > Thus programs trying to
> > > link in Xaw3d will fail since the link points to nothing!
> >
OK, there is a link that points to nowwhere, but nobody (not any
ordinary programme I know of) uses it. (because the Xaw3d dir
is above the X11R6/lib dir in /etc/ld.so.conf).
I'll remove the link in the next release, but it is only cleaning something
up, it isn't "broken".
> > What programme?
> >
> The VMS Ghostview. I will put the src via anonymous ftp from
> igor.girton.cam.ac.uk. It looks quite nice.
> > - if you mean /lib/ld.so:
> > again look at /etc/ld.so.conf, or the output of "/sbin/ldconfig -v",
> > and observe the order: /lib/ld.so will never look there for the libXaw,
> > it will look in .../lib/Xaw3d first.
> >
> It still remains that there is a broken link pointing to nothing which is
> found and was causing the link to fail (the link in the /usr/X11R6/lib
> dir that is).
That is what surprises me: apparently, you mean the dynamic link,
at execution time (not at compile/link time). But these links are
resolved by /lib/ld.so, and that will (or should) look for
/usr/lib/X11R6/Xaw3d/libXaw.so, when looking for libxaw.
You apparently want to dynamically link against libXaw3d.
I guess this may be neccecery for some programmes, who really know
about xaw3d -- but xaw3d is designed in such a way that this SHOULD
not be needed.
I do realise there is a problem with the current Xaw3d libraries
in that respect: there simply isn't a soname of Xaw3d, the xaw3d libraries
are compiled with a soname of Xaw. In that way, ld.so will NEVER find
Xaw3d if looking for something with a soname of Xaw3d (it's simply not there).
Let me explain why this is:
1 David Engel sugested a different sceme, some time ago, that solved
these problems: His idea was to compile the Xaw3d libs with a soname
of Xaw3d. In order for the xaw3d libs to be found when an app
(such as an ordinary xterm,xfig, whatever), I would also have
a stubb library with a soname of Xaw, that simply loads the
Xaw3d libs. I thought this was a wonderfull Idea, and released
xaw3d-1.2a-2 with that.
2 Problems arise: editres doens't work; the standard xaw "asciitext"
widget doens't work (THAT breaks *LOTS* of apps), and a lot more.
This apparently was because /lib/ld.so now loads Xaw (and thus Xaw3d)
before the other Xt/X11 libs (this also happend on HPUX, I tried it).
3 Thus, I went back to the Xaw soname of Xaw3d, and put the xaw3d
libs in their own dir that ld.so looks first. This is now how
ordinary Xaw programmes (xterm,,,) not compiled for Xaw3d find
the 3d libs.
Now, your app clearly is looking for Xaw3d. As far as I can see, it
would be best to persuade your GS to look for Xaw, in stead of Xaw3d
(it will find Xaw3d anyway).
Another solution would be along David Engel's stubb lib idea:
I COULD put a Xaw3d stubb dir that loads /../Xaw3d/libXaw.so in
the package. Unfortunately, this would (I guess) break all apps that
use, for example the asciitext widget, and many more, for the same
reasons as stated above.
> > > Also the headers are not included :(
> > And why would you want those? you should use the standard Xaw
> > headers, for all I know. (But maybe there are special cases
> > (certainly not normal) where you'd want the Xaw3d headers? Could
> > you tell me about them?)
> >
> Well GV _specifically_ stated that you needed those header. Who was I to
> quibble? Again, examine the src/readme in the tgz.
I, for one, am not to quibble. If the package says you need them,
then so be it. I was merely saying that *usually*, you don't need them.
Another point is: should they be in (my) Xaw3d?
I know the usual way to do this is release a devel package and a
normal package. But this is for those libraries that, if you
want to compile a programme with them, *always* need the devel
packages (i.e. the header files).
As it is with Xaw3d, you only need the "devel" version of it, if
you have a special programme that actually knows about the
xaw3d internals, and, as far as I know, there aren't many of those.
Because making more and more different packages (in this
case another xaw3dlib-dev package), adds a burden to both the
end-user and the maintainer, I'm reluctand to put together a
seperate devel package (just because it isn't needed in most cases).
BTW, I realise the "libXaw.a" that's currently in xaw3d should
probably be called "libXaw3d.a", and *should* also be in the
devel package, if released. But because I'm assuming anyone with
fast enough hardware that the xaw3d libs don't become anoying also
has enough diskspace, and doesn't mind about the 300k extra.
If there ever were a .devel package, then certainly this needs
to be put there.
When I started using debian, early this year, there wasn't a
Xaw3d package. As it is now, there is one that works OK
(first bug report in a long time), but it isn't perfect in that
it isn't split in two packages, nor does it allow for programmes
looking for libs with xaw3d sonames. I personally view these
drawbacks as very minor, as all programmes I know of don't
need this, appart from the VMS gs you told me about.
Could I (this time politely) ask you to extract the headers from
the .tar.gz package yourself (i.e., simply do as though there
isn't a debian xaw3d-dev package)?
I don't think there is a big need for a debian xaw3d-dev package,
so I'm not making one. But if you disagree, please make one
(and I'll remove the .a library from my package).
Thanks,
--
joost witteveen
joost@rulcmc.leidenuniv.nl
joostje@debian.org
--
Use Debian Linux!
Reply to: