SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You'd be surprised how much havoc a stray .pc file left simmering in /usr/share/pkgconfig along with a stray .so and/or .la library can play on a system with a compiler toolchain. I've had very few incidents with it minus one bad incident with zlib I had years ago on Mandrake, (someone tried to use a community package for zlib as libz... and it did enough damage to a build that even made the developer of the project stumped) but it never hurts to check for problems in unlikely places.
No I wouldn't. Which is why I have dedicated build boxes maintained absolutely clean using overlayfs and chroot. Also the problem was reported by Willy and I confirmed it, so it would be a stretch to hypothesise that cause for problems on two independent systems.
Not all of us have such luxuries like a few extra boxes unfortunately. However, let it be a good reminder for people to learn how to check and see if a system is clean for certain things and if maintenance is needed as such.
Not all of us have such luxuries like a few extra boxes unfortunately.
Luxuries??
The most powerful box I have is a desktop Dell OptiPlex 755 (Core 2 Duo 3GHz) that cost me £20 when an accountancy office bought new PCs. By the magic of distcc that's clustered with an Athlon 64 X2 Dual Core 5600+ box that I got for nothing because it was dead -- six caps on the mobo had blown, I recapped it and it's fine; and my desktop box, which is an Athlon 5000+; and a 3.2 GHz P4 with good old HT. My current lappie is a 1.8GHz Celeron that got fried when a neighbour spilt wine into it.
It makes me die a little inside when people in this forum say that a $100 graphics card is cheap. I can't afford that. But if you make yourself useful to people, eventually you'll get their junk, and if you have a brain you can make it sing.
Avogadro - Remove eigen3 before compiling source for slackware64-current (July 17th, 2015 update).
QtiPlot - Extract qtiplot-0.9.8.9.tar.bz2 into a separate directory. Change fold to qtiplot-0.9.8.9/3rdparty/qwtplot3d/3rdparty/gl2ps and edit gl2ps.c. Change line 819 from
as you seem to use the two, please try applying those during the build and report back if they solve your issues.
I'm also not sure that these issues are current-specific... in this case the fixes shouldn't go in my personal repository but in the main one (and should be reported to the respective maintainers, not here).
tl;dr avogadro and QtiPlot build ok with the suggested patches. Thanks to both of you!
Good work by slack_jack on diagnosing those problems (they were both on my "difficult problem" list), and good work by ponce finding those patches (I spent hours looking before you found them).
In the case of avogadro + eigen3, it's a -current problem since eigen3 was added to -current. The problem is that avogadro already has eigen3 support that is broken... if it had only eigen2 support, it would be ok :-/
In the case of QtiPlot, the code in gl2ps that detects zlib is commented out [1]. It's a -current problem because since the libpng-1.6 upgrade in -current, png.h no longer includes zlib.h [2]. The patch qwtplot3d-libpng15.patch isn't subtle, but it works.
[1] Why do developers write such unnecessarily complex code, then notice it doesn't work, and then just give up [3]? You'd expect that people who understand advanced data visualisation would also be able to understand a few simple includes, but apparently not *shakes head sadly*
[2] from my notes, these other packages might have a similar problem with libpng:
development/swfmill games/frogatto games/jezzball-kazzmir multimedia/tvtime
[3] QtiPlot is commercial software, so that is probably the explanation.
claws-mail builds fine here.
Those missing symbols are part of the kdepim and pilot-link packages (found by asking Mr Google btw).
So... take a wild guess what to do about that.
Edit: Look what I found. You know when we say people should have a full installation unless they are clever enough to solve their own problems with missing packages? *sigh*
Thanks! Your google searches seem to have been more fruitful than mine. I don't have any kde packages so its my fault, first time I have had this issue...
Well, I asked in #claws @ freenode, apparently I just need --disable-jpilot in the slackbuild which disables something that supposedly may not even work anymore. (I must of really been on the ball to miss that in ./configure --help). Also a claws-mail dev clearly told me "Claws doesn't rely on kde pim".
Quote:
Originally Posted by 55020
Edit: Look what I found. You know when we say people should have a full installation unless they are clever enough to solve their own problems with missing packages? *sigh*
I have already said this elsewhere, but out of 172+ slackbuilds installed claws-mail was the only one that seemed to need a kde package, but now it seems that may of not even been true and it really needed the jpilot slackbuild, which I unfortunately can not easily test since it doesn't compile here and I'm not really that fussed to figure out why... I stand by that there is no or possibly very little need to have kde, kdei, or xfce packages installed if you do not use any packages clearly associated with those projects. Possibly one slackbuild out of 172+ is not very much reason to preach that everyone must have a full install as a few users here do, if it was a clearly bad idea to remove kde and xfce from a slackware system they wouldn't be isolated in their own package series.
hi orbea, don't know what's happening there with jpilot, maybe you can get more informations out of the config.log inside the sources.
what I can tell you is that on my full installations of slackware64-14.1 and slackware64-current I just built:
- libetpan and claws-mail
- jpilot (after those, so seems not to be a dependency)
Quote:
Possibly one slackbuild out of 172+ is not very much reason to preach that everyone must have a full install as a few users here do, if it was a clearly bad idea to remove kde and xfce from a slackware system they wouldn't be isolated in their own package series.
let me say that:
- you are getting the numbers really wrong;
- luckily the people not doing a full install are a minority;
- the package sets are not related to complete isolation;
- on SBo only full installs are supported: if you don't install some package set (well, maybe this is not true just for the kdei set) it's not guaranteed that all the stuff from there will build.
so, please, service message for all: avoid reporting issue in this thread if you are not running a slackware current full install.
if you are running a subset of the full install and you have building issues report only if you are *absolutely sure* that it's not related to local missing dependencies.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.