version `GLIBC_2.14' not found

All questions about how to use KryoFlux go here.
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 3:08 am

Looks like I figured it out thanks to some help from the Arch devs - could someone please try the attached file and let me know if it works? I've got 2.0b9 ready to go (ADF write support) so if this fix works I'll apply it to b9 before releasing it.
Attachments
dtc-2.0b7-20120226-linux-x86_64.bz2
DTC 2.0b7 w/ ld-linux fix
(76.89 KiB) Downloaded 103 times

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

Re: version `GLIBC_2.14' not found

Post by TeaRex » Sun Feb 26, 2012 2:32 pm

Malvineous wrote:Looks like I figured it out thanks to some help from the Arch devs.
Nope, unfortunately it's still looking in /lib for its dynamic linker. If it's not there it will balk.

Maybe the reason this library isn't in /lib on Ubuntu has something to do with it being the dynamic linker rather than a normal library? I think the absolute path to the linker is always hard-coded into dynamically linked ELF binaries, unlike the path to other libraries which are resolved by the linker. But to be honest I wouldn't know whom to ask about that.

Let me also suggest leaving it at that, telling the user in a README file about it and releasing. The user has to know about blacklisting the cdc_acm module anyway so you might just as well add this symlink thing. The symlink doesn't seem to hurt in any case - as I said binaries contain the absolute path to their wanted linker anyways, so the normal library search procedure doesn't apply here and nothing is likely to be confused.

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

Re: version `GLIBC_2.14' not found

Post by shirsch » Sun Feb 26, 2012 6:25 pm

Malvineous wrote:Looks like I figured it out thanks to some help from the Arch devs - could someone please try the attached file and let me know if it works? I've got 2.0b9 ready to go (ADF write support) so if this fix works I'll apply it to b9 before releasing it.
Works fine here on Ubuntu Lucid (10.04) system.

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

Re: version `GLIBC_2.14' not found

Post by wuffe » Sun Feb 26, 2012 10:40 pm

Malvineous wrote: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.
No, I'm arguing for maximum compatibility for both 32bit and 64bit releases. In your post you minoritized the need for a 64bit version implying that it propably wasn't used by anyone - other than a few that needs performance
Malvineous wrote: I figure people running a 64-bit OS are doing so for performance reasons...
That quote I responded to - indicating that we are in the year 2012 and 64bit is at least as important if not more important that 32 bit.
Geeks are the first to switch to new technology such as 64bit - i did not say anything about the freshness of their installation.

From the feedback in this thread it seems that the 32 bit (SID) has no problems - so why not build 64bit from the same recipe ? If your Makefiles are well-written you should be able to build for 32 and 64 bit on the same platform - but that's another story.

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 » Mon Feb 27, 2012 12:12 am

Guys,

regardless of reasons and religion... everyone uses the OS he likes most (or "deserves"), and we try to support the majority of them. This is not easy, we don't have big teams like some companies do. Linux is problematic due to the broad range of variants, and I think Adam is doing a great job supporting them. To my knowledge, the 32bit version works across all of them, and the 64bit version just got better again.

I am also happy to announce that we're working on getting rid of the blacklisting of the modem driver that wants to hook the device all the time. This was Adams idea and I think we do have a way around that, if the latest firmware is stable.

We don't need upset anyone by implying things. It only makes communication worse and lowers morale and motivation. Thanks,

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 » Mon Feb 27, 2012 12:27 am

TeaRex wrote:Nope, unfortunately it's still looking in /lib for its dynamic linker. If it's not there it will balk.

Maybe the reason this library isn't in /lib on Ubuntu has something to do with it being the dynamic linker rather than a normal library? I think the absolute path to the linker is always hard-coded into dynamically linked ELF binaries, unlike the path to other libraries which are resolved by the linker. But to be honest I wouldn't know whom to ask about that.

Let me also suggest leaving it at that, telling the user in a README file about it and releasing. The user has to know about blacklisting the cdc_acm module anyway so you might just as well add this symlink thing. The symlink doesn't seem to hurt in any case - as I said binaries contain the absolute path to their wanted linker anyways, so the normal library search procedure doesn't apply here and nothing is likely to be confused.
Hmm, ok, for some reason despite double-checking I managed to attach a non-fixed version to that message... Well at any rate the upcoming 2.0b9 is definitely looking in /lib64 as I've checked about 100 times :-)

The Arch devs said the reason why it is in /lib on Arch is because historically it was a pure 64-bit distro (no 32-bit apps) and they only had /lib. I guess if Ubuntu was always multilib they decided to keep /lib for 32-bit binaries only.

If we can't get it fixed then I'll update the README, but I'd rather it just worked with minimal distro-specific fiddling. As mr.vince said, there's a firmware fix currently being worked on, and if that passes all the tests then there will no longer be a need to blacklist cdc_acm anymore which will be one less thing to worry about.
wuffe wrote:That quote I responded to - indicating that we are in the year 2012 and 64bit is at least as important if not more important that 32 bit.
Geeks are the first to switch to new technology such as 64bit - i did not say anything about the freshness of their installation.

From the feedback in this thread it seems that the 32 bit (SID) has no problems - so why not build 64bit from the same recipe ? If your Makefiles are well-written you should be able to build for 32 and 64 bit on the same platform - but that's another story.
Fair enough. I hadn't thought of cross-compiling, but I don't think you can compile a 64-bit app under 32-bit Debian. And doing it the other way would mean all the Arch problems would be extended to the 32-bit app as well :-) At any rate, it looks like this issue will hopefully be solved with the next release, which is due any day now...

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

Re: version `GLIBC_2.14' not found

Post by wuffe » Mon Feb 27, 2012 12:52 am

Malvineous wrote: I hadn't thought of cross-compiling, but I don't think you can compile a 64-bit app under 32-bit Debian
Me too - I've only compiled for 32bit on a 64bit platform - never tried the other way around.
Theoretically it should be possible - but I have a feeling that the other way around is exercised by more people/users :-)

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

Re: version `GLIBC_2.14' not found

Post by Tor » Mon Feb 27, 2012 11:25 am

Malvineous wrote:Looks like I figured it out thanks to some help from the Arch devs
It doesn't work on Debian SID still. It's got /lib/ld-linux-x86-64.so.2 in its image still (check with 'strings').
However, by adding a symlink in /lib on my machine to /lib64 for that file it works, as suggested by an earlier poster (thanks!).

As for the cause of the problem, it isn't that /lib is 32-bits on 64-bit Debian (and presumably Ubuntu), because there are 64-bit libs there. The reason is, I think, that that file is really the dynamic linker and not a library, so it's in /lib64. There is in fact a symlink /lib/ld-linux.so.2 -> /lib32/ld-linux.so.2 there already, and this _is_ for historical reasons - 32-bit applications, particularly those from pre-multiarch systems, expect to find a 32-bit dynamic linker there. So it makes kind of sense that we add a symlink to a 64-bit dynamic linker there, to support applications from a historically non-multiarch _64_-bit system. It's in a way symmetric to the 32-bit situation.

-Tor
Hostinfo: Debian SID x86_64 and i686

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 » Sat Mar 03, 2012 2:47 am

Any luck with the latest Linux release? (2.0b9)

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

Re: version `GLIBC_2.14' not found

Post by TeaRex » Sat Mar 03, 2012 3:30 pm

Malvineous wrote:Any luck with the latest Linux release? (2.0b9)
I can run it on Ubuntu Oneiric, without the need to create symlink to the linker in /lib. I mean it doesn't crash or refuse to run, but I haven't yet tried to use it to actually read or write disks. Still waiting for the NEC floppy drive to arrive...

Post Reply