version `GLIBC_2.14' not found

All questions about how to use KryoFlux go here.
User avatar
mr.vince
Posts: 2120
Joined: Tue Oct 05, 2010 5:48 pm

Re: version `GLIBC_2.14' not found

Post by mr.vince » Sat Feb 18, 2012 2:26 pm

Malvineous wrote:Well the ideal solution of course would be for DTC to become open source, then it wouldn't be a problem :-)
To comment on this before it becomes the major subject of discussion. We would love to do that but for many reasons not an option right now. That's the way it is.

shirsch
Posts: 19
Joined: Fri Feb 03, 2012 3:04 am

Re: version `GLIBC_2.14' not found

Post by shirsch » Sat Feb 18, 2012 5:35 pm

mr.vince wrote:
Malvineous wrote:Well the ideal solution of course would be for DTC to become open source, then it wouldn't be a problem :-)
To comment on this before it becomes the major subject of discussion. We would love to do that but for many reasons not an option right now. That's the way it is.
Personally, I don't care if dtc is open source or not, as long as the KF folks provide timely and effective support. So far, this project appears to be professionally run and responsive. Heck, Christian was able to speak about the project on the Classic Computer mailing list without getting eaten alive :-). That's impressive, given the opinionated and often crusty personalities there!

shirsch
Posts: 19
Joined: Fri Feb 03, 2012 3:04 am

Re: version `GLIBC_2.14' not found

Post by shirsch » Sat Feb 18, 2012 5:35 pm

Malvineous wrote:Well the ideal solution of course would be for DTC to become open source, then it wouldn't be a problem :-)

I investigated further and it looks like only the memcpy() function is pulling in the 2.14 dependency, and there's a way to override it. I have set it back to 2.2.5 (the same version as all the other symbols) so can you try out this version and let me know if it works any better?
Works fine - thanks for the effort!

Tor
Posts: 28
Joined: Mon May 16, 2011 3:08 pm

Re: version `GLIBC_2.14' not found

Post by Tor » Mon Feb 20, 2012 10:32 am

Well, the `GLIBC_2.14' not found' message disappeared (as reported by 'ldd'). However, I can't get it to execute on Debian SID (64-bit). Output from ldd looks fine, but execve refuses to run it - it exits immediately with 'exec: No such file or directory' (as reported by strace. ENOENT, in any case). Well, the file is there, I think I've seen that problem only when trying to execute a file from another (wrong) architecture. I may look at it again later, after work.

-Tor
Hostinfo: Debian SID x86_64 and i686

wuffe
Posts: 43
Joined: Thu May 19, 2011 7:05 pm

Re: version `GLIBC_2.14' not found

Post by wuffe » Sat Feb 25, 2012 12:03 am

Tor wrote:Well, the `GLIBC_2.14' not found' message disappeared (as reported by 'ldd'). However, I can't get it to execute on Debian SID (64-bit). Output from ldd looks fine, but execve refuses to run it - it exits immediately with 'exec: No such file or directory' (as reported by strace. ENOENT, in any case). Well, the file is there, I think I've seen that problem only when trying to execute a file from another (wrong) architecture.
-Tor
I have exact the same problem with the new binary on Ubuntu 11.10/x86_64 - same observations as Tor :-(

wuffe
Posts: 43
Joined: Thu May 19, 2011 7:05 pm

Re: version `GLIBC_2.14' not found

Post by wuffe » Sat Feb 25, 2012 12:17 am

Malvineous wrote:Debian's pretty conservative, even Sid isn't updated all that frequently. The 32-bit builds are done on Debian Squeeze (stable) so you shouldn't have to worry about new library versions there. I figure people running a 64-bit OS are doing so for performance reasons, so the 64-bit builds are done on Arch Linux with the latest and greatest library versions available.
No offence but we are in the year 2012 - and just like Windows users Linux users have also turned to 64bit - Intel/AMD CPUs have been 64bit capable for quite some time now - and who wants to limit yourself with a 4Gb addressspace today ? I would believe that most of the users that use Kryoflux and Linux are "powerusers" running on 64bit platforms.

Tor
Posts: 28
Joined: Mon May 16, 2011 3:08 pm

Re: version `GLIBC_2.14' not found

Post by Tor » Sat Feb 25, 2012 12:20 pm

Yes, 64-bit users will probably soon be the majority, if not already. And it's not for faster execution (as in CPU-like faster), it's because modern computers has lots of memory. Or if it hasn't, you will want it, because modern web-browsing needs tons of memory the way web-pages are made these days and the way browsers give you tabs and windows and whatnot. So either you start with lots of memory, or you're forced to add it, eventually. And if you don't want to run the poor hack that is called a PAE-kernel (which gives limited access to more physical memory through another indirection layer) then you can't use that physical memory unless you install the 64-bit version of your Linux OS.

So, the assumption that 64-bit Linux users are power/performance users is wrong, and thus it's wrong to assume that there's some bleeding edge to this. 64-bit builds should be built conservatively, that is, on an as old as possible setup in order to be binary compatible with as many distributions as possible. So a bleeding edge Arch Linux distro is the completely wrong one for this.

-Tor
Hostinfo: Debian SID x86_64 and i686

TeaRex
Posts: 120
Joined: Tue Nov 30, 2010 5:36 am

Re: version `GLIBC_2.14' not found

Post by TeaRex » Sat Feb 25, 2012 7:29 pm

Tor wrote:Well, the `GLIBC_2.14' not found' message disappeared (as reported by 'ldd'). However, I can't get it to execute on Debian SID (64-bit). Output from ldd looks fine, but execve refuses to run it - it exits immediately with 'exec: No such file or directory' (as reported by strace. ENOENT, in any case).
The solution is less than perfectly obvious:

cd /lib
sudo ln -s /lib64/ld-linux-x86-64.so.2

Now it should work. Who says DLL hell exists only on Windows?

wuffe
Posts: 43
Joined: Thu May 19, 2011 7:05 pm

Re: version `GLIBC_2.14' not found

Post by wuffe » Sat Feb 25, 2012 9:22 pm

Tor wrote: So, the assumption that 64-bit Linux users are power/performance users is wrong, and thus it's wrong to assume that there's some bleeding edge to this.
That was not what I wrote (well - english is not my native language) - by the term "poweruser" I meant a user that is technocally orientated (one could call it a geek/nerd) - and these types are the most likely to turn to new technology (such as 64bit) - not because they need it - but because it is interesting new technology. My guess is that this describe the most of the (non-commercial/private) users of Kryoflux - wheter it be a windows or linux user of kryoflux.
Tor wrote: 64-bit builds should be built conservatively, that is, on an as old as possible setup in order to be binary compatible with as many distributions as possible. So a bleeding edge Arch Linux distro is the completely wrong one for this.
+1 Agree

User avatar
Malvineous
Posts: 156
Joined: Sun Oct 31, 2010 10:57 pm
Location: Brisbane, Australia
Contact:

Re: version `GLIBC_2.14' not found

Post by Malvineous » Sun Feb 26, 2012 2:14 am

I'm confused - first you say 64-bit platforms are used by geeks who use it just because it's new and interesting, but then you say you don't want me to use library versions that are new and interesting also??? I think what you really mean is that you want the newest stuff that your ancient distro supports :-P At any rate it's not going to be easy, there has already been a problem fixed because some distro used a version of libusb that was newer than Arch, so the best we can hope for is to just fix these problems as they arise. And I am happy to do this, but please, there is no point in complaining because it is never going to work perfectly every time until DTC becomes open source.
TeaRex wrote:
Tor wrote:Well, the `GLIBC_2.14' not found' message disappeared (as reported by 'ldd'). However, I can't get it to execute on Debian SID (64-bit). Output from ldd looks fine, but execve refuses to run it - it exits immediately with 'exec: No such file or directory' (as reported by strace. ENOENT, in any case).
The solution is less than perfectly obvious:

cd /lib
sudo ln -s /lib64/ld-linux-x86-64.so.2

Now it should work. Who says DLL hell exists only on Windows?
Thanks for the info. It seems Arch stores that file in /lib, and symlinks it from /lib64 (opposite to what you had to do.) All the other libraries are linked to /lib so I'm not sure why this particular one is missing from /lib under Ubuntu and Debian. Can you ask them to find out why? In the mean time I will try to find some way of linking to /lib64 instead of /lib for just this one file.

Post Reply