Some new libraries required, not fetched by autopackage

[fuxoft]

I tried to update from rev.1615 to rev.1635 today but it doesn't start on my Ubuntu Dapper Drake because some libraries are missing. I installed libpng3 by hand but now it complains about "libtiff3" which is not available in Ubuntu repositories (it's not content with libtiff4).

fuxoft@frantisek:~$ xaralx
xaralx: error while loading shared libraries: libtiff.so.3: cannot open shared object file: No such file or directory

[penguin]

Same on my system.
I use kanotix, an unstable debian.
I installed lipgng but cant find the libtiff.so.3 with ark.

the following showes the console:
cw@supi:~/zeitweise xara/xaralx0.7_rev1635/xaralx/bin$ xaralx
xaralx: error while loading shared libraries: libtiff.so.3: cannot open shared object file: No such file or directory



with the help of another linuxer in our chat I did the following
open a console (hope its the correct word in english) (shell), in german it's "Konsole"
did you install the libtiff4? yes?
then you can type in the console/shell as root:
root@supi:~# ln -s /usr/lib/libtiff.so.4 /usr/lib/libtiff.so.3
then you will find a libtiff.so.3 in this directory and xara will start.

[Soquili]

I received a similar error after installing the r 1635 release. Reinstalled r 1623 to prevent withdrawal symptoms

A day without Xara Xtreme isn't healthy

There were no errors during the installation of r 1635, but when trying to start Xara Xtreme from the GUI I see an indication that Xara Xtreme is starting but it goes away and the program never starts. Starting from the console presented the attached message.

Debian 3.1r2 and Gnome 2.8.1

EDIT: Downloaded r 1638 and installed it. Get the same error message when trying to run Xara Xtreme LX that I got with r 1635.

[GerryI]

There were some problems with a change made to our build server. It has been corrected but you will have to wait for r1640 or later.

Gerry

[Soquili]

Thanks Gerry. I'll download the latest revision when I get home from work this evening.

[Odat]

Just downloaded and installed r1650 on two machines, my home machine running Slack 10.1, and my work machine running Slack 10.2. There still seem to be library issues, though I'm not sure if they're related to the previous ones or not. This is regarding libstdc++.so.6.

Under Slack 10.1, the package installed fine, but won't run, because I don't have libstdc++.so.6 installed at all.

Under Slack 10.2, the package installs, but the last thing the installer prints to the console is:

err:installExe()1290: bin/xaralx cannot be run on this system.

On this machine, I do have libstdc++.so.6 installed, but apparently a slightly previous revision, because when I attempt to run the binary I get:

/usr/lib/libstdc++.so.6: version `CXXABI_1.3.1' not found (required by .local/bin/xaralx)

I had revision r1623 installed on both previously, so either this is a library that used to be statically linked, but it no longer isn't, or the inclusion of something new (SVG filter perhaps?) now requires the library where previously it was not needed.

Either way, I would expect the package installer to tell me in both cases that the binary won't run, which it doesn't.

[abligh]

Just downloaded and installed r1650 on two machines, my home machine running Slack 10.1, and my work machine running Slack 10.2. There still seem to be library issues, though I'm not sure if they're related to the previous ones or not. This is regarding libstdc++.so.6.

Under Slack 10.1, the package installed fine, but won't run, because I don't have libstdc++.so.6 installed at all.

We are moving from requiring libstdc++.so.5 to libstdc++.so.6 for the autopackage builds. We will probably produce a libstdc++.so.5 edition of the recommended version. The reason for this is that using libstdc++.so.5 severely restricts our choice of compiler, which results in slower and (for technical reasons) much larger binaries. Most modern distributions come with libstdc++.so.6. You should be able to install libstdc++.so.6 on your system through the appropriate package call - that's what I recommend doing.

You are quite right that the installer should error.

Under Slack 10.2, the package installs, but the last thing the installer prints to the console is:

err:installExe()1290: bin/xaralx cannot be run on this system.

On this machine, I do have libstdc++.so.6 installed, but apparently a slightly previous revision, because when I attempt to run the binary I get:

/usr/lib/libstdc++.so.6: version `CXXABI_1.3.1' not found (required by .local/bin/xaralx)

Hmmm... it shouldn't do /that/. I would hope we'd work on any libstdc++ v6 system. Please could you file a bug report at http://bugzilla.xaraxtreme.org/
including the output of

  ldd -v /path/to/xaralx

I had revision r1623 installed on both previously, so either this is a library that used to be statically linked, but it no longer isn't, or the inclusion of something new (SVG filter perhaps?) now requires the library where previously it was not needed.

Us changing the C library. We haven't quite finished yet.

Either way, I would expect the package installer to tell me in both cases that the binary won't run, which it doesn't.

This is a reasonable requirement! What we should probably do is compile a tiny program that does just returns "1", and test that runs within the installer.

Alex

[Odat]

Hmmm... it shouldn't do /that/. I would hope we'd work on any libstdc++ v6 system. Please could you file a bug report at http://bugzilla.xaraxtreme.org/
including the output of

  ldd -v /path/to/xaralx

Alex

Before I fully commit to making myself look like a doofus in the bugzilla archives:

dart:D:~/.local/bin> ./xaralx                                                                                                             
./xaralx: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.1' not found (required by ./xaralx)

dart:D:~/.local/bin> strings /usr/lib/libstdc++.so.6 | grep CXXABI
CXXABI_1.3

It seems to me like the issue here is that I have a slightly older version of the library, which technically isn't a bug. I'd expect that if the ABI version changed in a meaningful way, the library name should be different. Since it's such a minor revision, I should still be able to link against it, but I can't because the linker is looking for a specific symbol when it shouldn't be.

However, I'm not overly familiar with the internal workings of how the dynamic linker decides which libraries to use, so my supposition may well be in error. Assuming that this is in fact a problem with the build and not just me, I can go ahead and file the bug report. If not, I can try to find a more updated version of the library and slink away into the shadows.

[abligh]

It seems to me like the issue here is that I have a slightly older version of the library, which technically isn't a bug. I'd expect that if the ABI version changed in a meaningful way, the library name should be different. Since it's such a minor revision, I should still be able to link against it, but I can't because the linker is looking for a specific symbol when it shouldn't be.

Whatever the technical reason, it should (in my opinion) work where libstdc++6 is installed; and I was the one who suggested we move to libstdc++6. I am happy to vouch for your non-doofus status in any bug report :-) I suspect it is just a missing compile-flag to use a backwards compatible API but we'd be greatful for the bug report (plus ldd -v and some information on your system) so we can sort it out.

Alex

[Soquili]

Not to sound like a broken record and repeating things, but I still get the error about the missing libXfixes.so.3 when I try running r 1651.

Rev 1623 is the most recent version I can install and run.

Debian 3.1r2 Gnome 2.8.1

I'll wait for Odat to report the bug. I'm assuming it is the same for both our error messages.