[Slackbuilds-users] Error building inkscape-0.91

[Fernando Lopez]

I am the maintainer for inkscape. I only run 64 bits.

On Thu, Feb 25, 2016 at 4:55 PM, Duncan Roe <duncan_roe at acslink.net.au>
wrote:

> Hi all,
>
> This looks to me to be a problem for upstream. I'm posting here because of
> the
> workaround and also because I guess any bug report to upstream should come
> from
> the maintainer.
>
> At least on 32-bit, the SlackBuild terminates with this error:
> >   CXXLD    inkscape
> > /usr/lib/libdbus-glib-1.so.2: undefined reference to
> `dbus_message_iter_abandon_container'
> > collect2: error: ld returned 1 exit status
> > make[3]: *** [inkscape] Error 1
>
> In brief, the workaround is to complete the SlackBuild by hand, inserting
> "-ldbus-1" near the end of g++ lines that invoke ld (one for inkscape, one
> for
> inkview).
>
> THE WORKAROUND
>
> To get the g++ command line, as root cd to /tmp/SBo/inkscape-0.91 and run
> > make V=1
> redirecting output to a file. Edit this file into a shell script e.g.
> > #!/bin/sh
> > cd /tmp/SBo/inkscape-0.91/src
> > g++ -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual ...
>
> The g++ line above is over 16KB but vi copes. At the end, change
>  > /usr/lib/libglib-2.0.so -pthread -fopenmp
>  to
>  > /usr/lib/libglib-2.0.so -ldbus-1 -pthread -fopenmp
>
> Now run make. It will fail similarly when loading inkview. Repeat steps
> above.
>
> Run make again. It will complete.
>
> Paste in to your root build xterm enough of the SlackBuild to set all the
> upper-case shell variables (i.e. from "TMP=" through "fi"). Set CWD to be
> the
> original directory containing inkscape.SlackBuild. Your curent working
> directory
> should still be /tmp/SBo/inkscape-0.91.
>
> To be safe, re-issue the mkdir -p at line 60 (I changed it to -pv and it
> claimed
> to make something).
>
> Paste in and execute everything from the make install on line 84 onwards.
>
> SOME KIND OF AN EXPLANATION
>
> The g++ line doesn't mention libdbus-glib-1. It seems some other .so is
> pulling
> it in as a dependency.
>
> As it happens, I have a tool, findit(*), which can investigate this sort of
> problem. It agreed with ld:
> > 23:45:32# findit /usr/lib/libdbus-glib-1.so.2
> dbus_message_iter_abandon_container
> > /usr/lib/libdbus-glib-1.so.2: undefined symbol:
> dbus_message_iter_abandon_container. (dlsym)
>
> /usr/lib/libdbus-glib-1.la advertises a number of dependencies:
> > # Libraries that this one depends upon.
> > dependency_libs=' /usr/lib/libdbus-1.la -lrt /usr/lib/libgio-2.0.la ...
>
> libdbus-1.la only shows -lpthread -lrt as dependencies. Ignoring that:
> > 23:58:31# findit -ldbus-1 /usr/lib/libdbus-glib-1.so.2
> dbus_message_iter_abandon_container
> > Found dbus_message_iter_abandon_container in
> /usr/lib/libdbus-glib-1.so.2 at 0xb75a9fb0
>
> It's been my experience in the past that shared libraries will sometimes
> provide
> a symbol without loading dependencies and sometimes they won't. Or the same
> shared library may provide some symbols and not others. Hence the
> workaround.
>
> WHERE IS THE BUG REALLY?
>
> I would say the fault lies with whatever library is pulling in
> libdbus-glib-1.
> It should also pull in libdbus-1. Maybe someone will "just know" which
> library
> "it" is.
>
> Cheers ... Duncan.
>
> (*) findit is part of https://github.com/duncan-roe/command_line_tools
>     If you would like it, feel free to take a clone
>



-- 

------------
Regards,
    Fernando Lopez Jr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20160225/a274500d/attachment.html>