Skip to content

cannot run C compiled programs

Every now and then I come across this message, but apparently far too seldom, otherwise I would've remembered:
$ uname -sr
NetBSD 4.0.1
$ ./build.sh tools
[...]
No nonexistent/bin/nbmake, needs building.
Bootstrapping nbmake
checking for sh... /bin/sh
checking for gcc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... configure: error:
 cannot run C compiled programs.
If you meant to cross compile, use `--host'.
That's a weird way for saying that /tmp is mounted noexec :-\

scp between two different hosts

Every now and then I try to scp files between two hosts with just one command. But it mysteriously fails with:
$ scp bob@saturn:/tmp/foo alice@pluto:/tmp/bar
bob@saturn's password: 
Permission denied, please try again.
But the password for bob@saturn is definitely right (I promise!), so what's going on here? Let's take a closer look:
$ scp bob@saturn:/tmp/foo alice@pluto:/tmp/bar
bob@saturn's password: 
^Z
$ ps -ef | grep [s]cp
[...] scp bob@saturn:/tmp/foo alice@pluto:/tmp/bar
[...] /usr/bin/ssh -x -oClearAllForwardings yes -n -l bob saturn \
       scp /tmp/foo alice@pluto:/tmp/bar
Now we see that scp(1) was actually executed on the saturn. The Permission denied was already pluto's response to the connection attempt. After stumbling over this issue a few times I finally found a nice explanation describing all this.

Git plus Perl 5.10 with MacPorts on MacOS 10.4

Since the Fink Project looks a bit stale (last release from 06/2008), I switched to MacPorts, which does not come with a neat dpkg toolset, but the port command is usable too (and looks more BSD-like anyway ;)). One of the tasks left was to compile git-core. Of course, git-core has runtime dependencies on perl and a package called p5-error. However, there are 3 different "perl" packages available: perl, perl5.8, perl5.10. Since perl5.10 was already installed, I was looking for a way to convince git-core to depend on perl5.10 instead. Since p5-error also had a library dependency on perl5, I had to add a depends_lib port:perl5.10 to its Portfile. Run "portindex" once more, now we should be ready to install git-core (for perl5.10). Here's the full procedure:
$ cd
$ mkdir -p .ports/devel/git-core/files .ports/perl/p5-error
$ cd .ports
$ cp $macports/.../release/ports/devel/git-core/Portfile \
   devel/git-core/
$ cp $macports/.../release/ports/devel/git-core/files/patch-Makefile.diff \
   devel/git-core/files/
$ cp $macports/.../release/ports/perl/p5-error/Portfile \
   perl/p5-error/
* Change depends_run to path:bin/perl:perl5.10 in devel/git-core/Portfile
* Add depends_lib port:perl5.10 to perl/p5-error/Portfile
$ portindex
$ sudo port install git-core
....and that should be all, for building git-core that is.

unable to set superblock flags

An ext3 filesystem would not mount today :(
Running e2fsck (under MacOS 10.4/ppc) only gave:
$ e2fsck -fv /dev/rdisk0s4
fsck.ext3: unable to set superblock flags on /dev/rdisk0s4
Then I remembered to try with a dfferent superblock, and it worked perfectly:
$ mkfs.ext3 -n /dev/disk0s4 
[...]
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Note: Don't forget the -n option, otherwise mkfs.ext3 will really format the partition!
 
$ e2fsck -b 32768 -fv /dev/rdisk0s4 
[...]
$ mount_ext2 /dev/disk0s4 /Volumes/disk0s4/
Now mounting succeeds again. Yeah, ext3 ;-)

APT::Install-Recommends

I wonder why this parameter has been turned on. It confuses users and does things like:
# apt-get install mdadm
[....]
The following extra packages will be installed:
  citadel-common citadel-mta citadel-server db4.6-util libcitadel1 
  libcurl3 libglib2.0-0 libglib2.0-data libical0 libpcre3 libsieve2-1
  libssh2-1 libxml2 sgml-base shared-mime-info xml-core
[....]
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
I mean, what the hell, man? Why would I need citadel-server, which apparently is described as "a complete and feature-rich open source groupware platform" - huh? I only wanted to install mdadm! Fortunately one can set APT::Install-Recommends "false"; in apt.conf, and it'll just install with Depends: from now on.

tcpd & 127.0.0.1

I really like the tcpwrapper. Without messing with ipfilter, one can easily set up quite a few access rules. While running seccheck, I noticed that TCP wrappers were not enabled on my system. A quick edit of hosts.allow and hosts.deny did the trick - except for sendmail:
[ID 801593 mail.info] n28820cE016260: from=root, size=247, class=0, nrcpts=1, 
                      msgid=<200903080802.n28820cE016260@node1>, relay=root@localhost
[ID 801593 mail.notice] n28820u0016261: tcpwrappers (localhost, 127.0.0.1) rejection
So, why would sendmail reject mail from localhost? Well, sendmail is linked against the TCP wrapper too:
$ ldd /usr/lib/sendmail | grep wrap
        libwrap.so.1 =>  /usr/sfw/lib/libwrap.so.1
$ grep -v ^\# /etc/hosts.allow 
ALL: 127.0.0.1/255.0.0.0
ALL: 10.200.0.0/255.255.255.0
Apparently sendmail (or, to be correct: tcpd) does not like the subnet after 127.0.0.1, despite the manpage where it expects an "expression of the form `n.n.n.n/m.m.m.m' ". Well, removing the subnet helped, now sendmail delivers to localhost again.

~/Desktop pollution

Sigh, when will it end? The most userfriendly (Desktop)OS on earth right now still has so many issues. But why wouldn't it, considering the rather large userbase. Hmpf. As Safari does not fit my needs (don't ask) I'm stuck with Firefox (sometimes even Minefield). But every time I click on a document which a helper application is about to open (.m3u, .pdf, etc.), Firefox stores a temporary copy on my desktop. Only that it's not temporary at all, but stays there until I delete it. So after a long browsing session, the desktop is cluttered with not-so-temporary documents. Oh, there's #302433 (opened 07/2005, marked "fixed" while it's actually not) and then there's #374184 (opened 03/2007, still open) but apart from a proposed workaround there really is no solution in sight. Bummer.

Update: A comment in #311292 proposed a new about:config option (browser.download.folderList) to be set to "1", so that downloaded files will temporary go to the system's default download directory. See also Comment #55 in the same report, that suggests to set this default download directory with Camino. Yes, "wow!" indeed. But it worked.