On Mon, 2008-09-01 at 12:57 +0200, Manuel Prinz wrote: > > I need the details of that patch, respective to the current patch set. > > Which file did you change? > > I created a cache file, mips-linux-gnu.cache, which had the same content > as the arm cache file for ncurses. That was everything needed to build > ncurses. That's a single line file - it doesn't relate the AR_OPTS AFAICT. $ cat arm-linux-gnu.cache cf_cv_wint_t=no > The error message I mentioned in your other mail was actually the one I > saw. In the second ./configure run of ncurses the test for the AR_OPTS > was not run, leaving AR_OPTS empty and causing the build to fail since > those are required to run ar. (Should be set to "rv", IIRC.) As said, > adding the cache file fixed it. I tried this twice. So I do not yet > understand why this fails on ARM, too. Maybe the problem is somewhere > deeper. Be careful copying cache files that are not in the Emdebian patch set - ./configure sets a whole load of stuff in cache that we don't want to retain, we only want the few cache keys that would break the build if missed out. What is the content of your mips-linux-gnu.cache file? (Check against the ncurses section of /etc/dpkg-cross/cross-config.cache) (hmm, must remember to make that alphabetical by package too.) Actually, I think there are a few other problems in ncurses - I'll update the patches. > To see what I describe above, you can search the buildlog for "checking > for arm-linux-gnu-ar". On the first configure run, you can see that it's > followed by a line reading "checking for archiver options (symbol > AR_OPTS)... rv" which is missing in the second run. So AR_OPTS seems to > be unset and uncached. OK, thanks for the tip - I'm checking the ncurses build and I'll see what is going wrong. > > > [1] I think I used the testing version, all paths were hard-coded. If > > > that's not fixed in the latest emdebian-tools, I could provide patches. > > > > I am not sure to what you are referring here. > > I was referring to the fact that the build logs have to reside > under /var/www/toolchain/buildd in order to be found by the .php > scripts. I modified the scripts so that one can change that via a > variable to match the local directory structure, if it is different. Ah, OK. That's a path from www.emdebian.org so it probably can be modified. (The actual path should be /var/www/buildd/ - the PHP lives in toolchain/ but the buildd logs in /var/www/buildd or a symlink that points to that directory. Rather than modifying the scripts, symlink the scripts to your local SVN checkout of emdebian-tools or your local installation of emdebian-tools (in /usr/share) and then create the symlinks to replicate the path. That allows you to keep the scripts in sync with changes in the package. e.g. I'm just adding support for 'emtargetcmp -m' for checks on the testing repository. One day, I'll make the path configurable. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part