From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10641 invoked by alias); 30 Aug 2010 21:48:24 -0000 Received: (qmail 10406 invoked by uid 22791); 30 Aug 2010 21:48:22 -0000 X-SWARE-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_NUMERIC_HELO,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Aug 2010 21:48:16 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OqCD5-0002T2-VT for systemtap@sources.redhat.com; Mon, 30 Aug 2010 23:48:11 +0200 Received: from 64.122.56.22 ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Aug 2010 23:48:11 +0200 Received: from grant.b.edwards by 64.122.56.22 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Aug 2010 23:48:11 +0200 To: systemtap@sources.redhat.com From: Grant Edwards Subject: Re: Hints for cross-compiling staprun? Date: Mon, 30 Aug 2010 21:48:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: slrn/pre0.9.9-102 (Linux) X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00324.txt.bz2 On 2010-08-30, Frank Ch. Eigler wrote: > grant.b.edwards wrote: > >> [...] >> I've hit a few glitches, but I'm making progress. One issue is that >> the configure script refuses to check for the existence of files when >> cross-compiling. [...] > > Perhaps we're using the wrong configure.ac directive to test for them. I'm not sure, but I don't think so. After googling the error message "cannot check for file existence when cross compiling" it seems to be a common issue among people who cross-compile things. I didn't see any suggested solution other than faking config cache entries by setting environment variables indicating whether the file was to be considered present or not. >> [...] >> The other problem is that the sources use a number of non-standard >> APIs without checking to see if they are, in fact, supported by the >> build environment. The ones that I tripped over are: >> >> index,rindex obsolete and not present in POSIX.1-2008. > > OK, will fix. Thanks! >> __progname doesn't seem to be part of any standard, and isn't >> present in any headers on any Linux system I've got. > > (Where do we refer to that?) Ah, my mistake. That's an undefined symbol in libssp, and apparently systemtap is the only thing on my target system that uses the offending portion of that library. >> It would result in a more graceful failure if the configure script >> checked for those. > > Well, we should be able to presume plain POSIX, but a few more tests > wouldn't hurt, I guess. You're right. You should be able to presume plain POSIX. I wouldn't bother adding tests for stuff that's required by POSIX. >> [...] >> If the systemtap Makefile.in is going to use "install-sh -D", >> shouldn't it come with an install-sh that supports "-D"? > > I guess on native linux boxes it was using /usr/bin/install, which > does understand -D. We should be able to adapt that to some > combination of -d / -t or mkdir -p. Will fix. It turns out that the only time that -D is used is when installing examples. Since there's no point in installing examples on a machine that has only the runtime, I nuked that section of Makefile.in. Now it builds and installs without problems (haven't tried actually using it yet). Adding a --disable-examples option is preferable to patching Makefile.in, but I haven't had time to figure out how to do that yet. -- Grant Edwards grant.b.edwards Yow! I didn't order any at WOO-WOO ... Maybe a YUBBA gmail.com ... But no WOO-WOO!