Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #171337 > unrolled thread

maxima, draw3d, and vtk

Back to article view | Back to linux.debian.user

Contents

  maxima, draw3d, and vtk Thomas Vaughan <tevaughan@gmail.com> - 2016-08-20 16:20 +0200
    Re: maxima, draw3d, and vtk Nicolas George <george@nsup.org> - 2016-08-20 17:00 +0200
      Re: maxima, draw3d, and vtk "Thomas E. Vaughan" <tevaughan@gmail.com> - 2016-08-20 17:50 +0200

#171337 — maxima, draw3d, and vtk

[Multipart message — attachments visible in raw view] — view raw

The 'draw3d' function defined in the 'draw' package for maxima is failing.
Before I file a bug report, I'd like to find out what package has the bug.
(Or find out if the bug be user error. :-)

I am running Debian unstable with maxima, vtk6, and tcl-vtk6 installed,
according to documentation here: http://riotorto.users.sourceforge.net/vtk/

The error output (pasted below) refers to a file that does not exist:
/usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so

Using 'dpkg -S libvtkCommonCoreTCL', I find
libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3.0
libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3

It looks to me as though there is something at least a bit broken about the
names of the libraries installed by the libvtk6.3 Debian package, but I'm
not an expert in library naming.

If you have an idea of what I might do to rectify the situation, then
please respond to all, because I am not a subscriber to the list.

Anyway, here is the error that I saw inside maxima:

(%i8) draw3d(color=white,elevation_grid(m,0,0,10,10));
(%o8)                                done
(%i9) couldn't load file "/usr/lib/x86_64-linux-gnu/
libvtkCommonCoreTCL-6.3.so": /usr/lib/x86_64-linux-gnu/
libvtkCommonCoreTCL-6.3.so: cannot open shared object file: No such file or
directory
attempt to provide package vtkCommonCoreTCL 6.3 failed: no version of
package vtkCommonCoreTCL provided
attempt to provide package vtkcommoncore 6.3 failed: no version of package
vtkcommoncore provided
Error in startup script: attempt to provide package vtk 6.3 failed: no
version of package vtk provided
    ("package ifneeded vtk 6.3" script)
    invoked from within
"package.orig require vtk"
    ("eval" body line 1)
    invoked from within
"eval package.orig $args"
    (procedure "package" line 2)
    invoked from within
"package require vtk"

-- 
Thomas E. Vaughan

[toc] | [next] | [standalone]

#171338

[Multipart message — attachments visible in raw view] — view raw

Le quartidi 4 fructidor, an CCXXIV, Thomas Vaughan a écrit :
> Using 'dpkg -S libvtkCommonCoreTCL', I find
> libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3.0
> libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3
> 
> It looks to me as though there is something at least a bit broken about the
> names of the libraries installed by the libvtk6.3 Debian package, but I'm
> not an expert in library naming.

A library normally exists as three files:

First, the actual library file, with a full version after the .so extension.
The other files will be symlinks to it.

Second, a symlink with just a major version mark after the .so extension.
This is called the SONAME, it can be queried with "objdump -p". This is the
name programs must use to access the library. It therefore must be changed
each time an incompatible change in the library ABI is made, for example
changing the type of a function argument.

Third, a symlink with just .so: this is accessed to support linking
libraries using the "-lsomething" linker options.

The actual file, of course, comes in the library package. The SONAME symlink
comes with it too, but it is really not necessary since ldconfig will
recreate them if necessary.

The .so file comes with the -dev package.

The SONAME symlink exists to allow several versions of the same library to
be present on the system at the same time. Otherwise, you would have to
rebuild all the packages that depends on it at the same time.

On the other hand, incompatible API changes are considered rare enough: no
provisions exist to allow the development files for several versions of the
same library to be present on the system at the same time. If it is
necessary, it either requires the developer to play with -L and -I paths, or
the name of the library needs to be changed, for example from gtk-2.0 to
gtk-3.0 (which are respectively at version 2.32.2 and 3.21.4; I wonder what
they were on when they decided to include the .0 in the name for the 3
branch).


Now, what can we tell about vtk? Well, you can see that the version number,
"6.3" is included both in the library name and as a suffix for the SONAME.
That tells us that the vtk people have decided not to care more about ABI
stability than API stability. Fine.

Still, the only acceptable way of accessing a library for a program (not
part of the library package) is though the SONAME. The maxima package is
definitely at fault.

The blame likely lies with the maxima people.

Still, there may be a case for another explanation: sometimes, the upstream
of a library does not understand the SONAME logic and just produces a
library file ending as .so, and the distribution maintainers add the SONAME
to make it a proper library. If that happens, programs that expect that will
not work without the -dev package. You can check that by compiling the
upstream libvtk and checking if it includes the SONAME.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#171339

On Sat, Aug 20, 2016 at 04:54:09PM +0200, Nicolas George wrote:
>
> Le quartidi 4 fructidor, an CCXXIV, Thomas Vaughan a ?crit?:
> >
> > Using 'dpkg -S libvtkCommonCoreTCL', I find
> > libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3.0
> > libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3
> > 
> > It looks to me as though there is something at least a bit broken about the
> > names of the libraries installed by the libvtk6.3 Debian package, but I'm
> > not an expert in library naming.
> 
> A library normally exists as three files:
> 
> First, the actual library file, with a full version after the .so extension.
> The other files will be symlinks to it.
> 
> Second, a symlink with just a major version mark after the .so extension.
> This is called the SONAME, it can be queried with "objdump -p". This is the
> name programs must use to access the library. It therefore must be changed
> each time an incompatible change in the library ABI is made, for example
> changing the type of a function argument.

Thanks for your excellent and clear response!  I see that the actual library
file and the SONAME link (which has the major version) are included in the vtk
packages that I have installed.

> Third, a symlink with just .so: this is accessed to support linking libraries
> using the "-lsomething" linker options.

It seems that maxima is trying to access a file that is ordinarily present only
when one might want to build an executable (or other library) and then link
against vtk.  Linking via '-lfoo' would also, in general, require header files,
which declare the symbols that are resolved by linking.  So I see why the link
ending in '.so' would be supplied by the '-dev' package.

> The .so file comes with the -dev package.

Right.

> Still, the only acceptable way of accessing a library for a program (not
> part of the library package) is though the SONAME. The maxima package is
> definitely at fault.

You seem to mean that the only acceptable way of accessing a library via
dlopen() is through the SONAME.  I presume that maxima is using dlopen(), but I
don't really know.  Clearly, one may access a library by linking to it (as with
'-lfoo') via the file that ends with '.so'.

> Still, there may be a case for another explanation: sometimes, the upstream
> of a library does not understand the SONAME logic and just produces a library
> file ending as .so, and the distribution maintainers add the SONAME to make
> it a proper library. If that happens, programs that expect that will not work
> without the -dev package. You can check that by compiling the upstream libvtk
> and checking if it includes the SONAME.

You seem to suggest that the Debian vtk developers might have made changes to
the build system to make the names of the library and the links be right,
though a bit different from upstream vtk, and that the Debian maxima developers
might not have caught a broken dependency on upstream naming when incorporating
the draw package into maxima.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web