Ld_library_path_vs._bcm4306

title: LDLIBRARYPATH vs. BCM4306 date: 2004-08-17 07:06:50

At the Pacific Slamatarium, SATURDAY! SATURDAY! SATURDAY!

I wrote earlier about a developer who found that ls, among other commands, would dump core when he went to a certain directory. What's more, it only worked for him, and only if he used tcsh -- if he switched to bash, everything was fine.

Well, I was a bit of an idiot for wondering if I should be compiling debug versions of ls. First clue was when he went to another directory nearby, ran ls and got this message: ls: error while loading shared libraries: libc.so.6: ELF file data encoding not little-endian What the...Then I realized that another significant thing about this was what was in the directories he was having problems with: different versions of GCC/glibc/Linux, cross- and native-compiled.

Okay, so somehow ld was looking in the current working directory for libraries to load (ack!). But why? I took a look at his environment and found:

LD_LIBRARY_PATH=:/home/foo/this:/home/foo/that:/usr/local/foo:/usr/local/bar [...]

Sure enough, take out that leading colon at the beginning and everything was fine.

I'm not sure right now if this would be a bug^wfeature of ld or the shell, but it was good to get to the bottom of it.

So the next thing to get working is wireless access. First of all, the Airport Extreme that we bought for the iBook will not do passive mode sniffing/tracking/blogging (still learning all this, so pls. correct errors in terminology); it uses a Broadcom chipset, and Broadcom is not interested in helping the folks at Kismac (thank you, Sam and anonymous stranger. Hm. And the Linksys WMP54GS won't work on my machine for two reasons:

1. It uses the BCM4306 chipset from Broadcom.
2. It needs a PCi2.2 motherboard, and I've got this old Abit BH6 which almost certainly isn't.

Back to the store with the PCI card, and the hunt will continue. I might get the WAP54 for the Linux-running coolness, but we'll have to see.