version `GLIBC_2.14' not found

[Malvineous]

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.

[TeaRex]

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]

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]

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 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

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.

[mr.vince]

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,

[Malvineous]

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.

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]

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]

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

[Malvineous]

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

[TeaRex]

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...