Re: GDC build [was: Re: Sort order of dirEntries]
On 10/26/2012 04:51 AM, H. S. Teoh wrote: Hmm. Try apt-get install libppl0.11-dev, maybe? That's where that file should be. AFAIK apt-get build-dep should've pulled that one in, but just in case it didn't, this may help. It's installed, but the headers in /usr/include/x86_64-linux-gnu/ instead of just /usr/include/ -- it's a multiarch thing again. So, I symlinked /usr/include/x86_64-linux-gnu/ppl* to /usr/include/ and that seems to get round it. I also tried running make without the -j4 option, in case there was something about the parallel build jobs that was screwing things up. So, now it falls over with a whole bunch of new errors, ending with the following: --- libbackend.a(tree-scalar-evolution.o): In function `gt_ggc_mx_scev_info_str(void*)': tree-scalar-evolution.c:(.text+0x4bd0): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree-scalar-evolution.o): In function `gt_pch_nx_scev_info_str(void*)': tree-scalar-evolution.c:(.text+0x4c91): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree-scalar-evolution.o): In function `gt_ggc_mx_scev_info_str(void*)': tree-scalar-evolution.c:(.text+0x4bdf): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree-scalar-evolution.o): In function `gt_pch_nx_scev_info_str(void*)': tree-scalar-evolution.c:(.text+0x4ca0): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o): In function `gt_pch_nx_type_hash(void*)': tree.c:(.text+0x785): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o): In function `gt_ggc_mx_type_hash(void*)': tree.c:(.text+0x844): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1ab8): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1ac0): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1ae8): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1af0): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1b78): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1b80): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1ba0): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1ba8): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1bc8): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1bd0): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1bf0): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1bf8): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1c18): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(tree.o):(.rodata+0x1c20): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x55b8): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x55c0): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x55e0): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x55e8): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5608): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5610): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x56f8): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5700): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5720): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5728): undefined reference to `gt_pch_nx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5748): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' libbackend.a(i386.o):(.rodata+0x5750): undefined reference to `gt_pch_nx_lang_tree_node(void*)' collect2: error: ld returned 1 exit status make[3]: *** [cc1d] Error 1 --- What's really annoying is that AFAICS all of these last errors occur at the point where the gdc executable is being linked ... :-\
Re: Sort order of dirEntries
On Thu, 25 Oct 2012 01:15:06 +0100, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Hello all, I've just been playing with dirEntries and by the looks of it, it returns these entries in arbitrary order. On windows, assuming it was using FindFirstFile or similar you would get alphabetical order on some platforms/file systems and FAT table order on others. I imagine linux and associated platforms have similar behaviour. Is there a way to get it to sort the entries in alphabetical order, other than the obvious one of storing them in an array and sorting that? (This is untenable because I'm talking about a lot of files...:-) To get a sorted list someone has to load all the entries and sort them. I doubt the file system is going to do it, so either the library routine would have to, or you're going to have to. As most file systems and libraries should take the most efficient approach first and foremost it's likely you're going to have to do it yourself. :) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: GDC build [was: Re: Sort order of dirEntries]
On Fri, Oct 26, 2012 at 02:36:18PM +0200, Joseph Rushton Wakeling wrote: On 10/26/2012 04:51 AM, H. S. Teoh wrote: Hmm. Try apt-get install libppl0.11-dev, maybe? That's where that file should be. AFAIK apt-get build-dep should've pulled that one in, but just in case it didn't, this may help. It's installed, but the headers in /usr/include/x86_64-linux-gnu/ instead of just /usr/include/ -- it's a multiarch thing again. Hmm. Are the Ubuntu patches incomplete then? I would've thought the patches in debian/patches should have taken care of this. So, I symlinked /usr/include/x86_64-linux-gnu/ppl* to /usr/include/ and that seems to get round it. I also tried running make without the -j4 option, in case there was something about the parallel build jobs that was screwing things up. I always built with -j6 (don't have the patience to wait that long) and that never seemed to have made a difference in whether the build succeeded. So, now it falls over with a whole bunch of new errors, ending with the following: --- libbackend.a(tree-scalar-evolution.o): In function `gt_ggc_mx_scev_info_str(void*)': tree-scalar-evolution.c:(.text+0x4bd0): undefined reference to `gt_ggc_mx_lang_tree_node(void*)' [...] Hmm. Googling for the missing symbol seems to relate it to LTO, so maybe try --disable-lto to see if that gets it through? Also, if you aren't already, make sure you start with a clean, empty objdir everytime you rebuild (I usually run \rm -rf *; configure ...; make -j6), because the miserable system doesn't know how to continue building from where it left off, and sometimes detritus leftover from previous attempts can interfere with the build. You probably already know this, but, just to make sure all bases are covered. T -- When solving a problem, take care that you do not become part of the problem.
Re: GDC build [was: Re: Sort order of dirEntries]
On 10/26/2012 06:57 PM, H. S. Teoh wrote: Hmm. Are the Ubuntu patches incomplete then? I would've thought the patches in debian/patches should have taken care of this. I've posted a follow-up to the d.gnu list, since that's really where this discussion belongs, but just to say you were probably right to suspect something was wrong with my application of the patches. I decided to download a fresh copy of the apt-get source and reapply the patches; now, with the symlinks removed, the build proceeds without the errors related to crti.o or header files. It still falls over in what looks like the same place as last described, though, even if I try the --disable-lto option. :-( Also, if you aren't already, make sure you start with a clean, empty objdir everytime you rebuild (I usually run \rm -rf *; configure ...; make -j6), because the miserable system doesn't know how to continue building from where it left off, and sometimes detritus leftover from previous attempts can interfere with the build. You probably already know this, but, just to make sure all bases are covered. Yea, it's what I was doing, removing and making a fresh build. Re the -j option, I still find that the build falls over in different ways depending on whether I use that option or not (cf. my post in d.gnu).
Re: Sort order of dirEntries
On 10/25/2012 02:30 AM, H. S. Teoh wrote: This may not be possible if the OS doesn't keep the entries in sorted order (and from what I know, most OS's don't; it's only sorted upon display). *Somebody* will have to do the sorting, whether it's the OS, or the library or user code. The performance penalty will still be incurred regardless. ... and interestingly enough the sort order seems to be different depending on the choice of compiler.
Re: Sort order of dirEntries
On Thu, Oct 25, 2012 at 04:22:43PM +0200, Joseph Rushton Wakeling wrote:
On 10/25/2012 02:30 AM, H. S. Teoh wrote:
This may not be possible if the OS doesn't keep the entries in sorted
order (and from what I know, most OS's don't; it's only sorted upon
display). *Somebody* will have to do the sorting, whether it's the
OS, or the library or user code. The performance penalty will still
be incurred regardless.
... and interestingly enough the sort order seems to be different
depending on the choice of compiler.
Oh, really? I couldn't reproduce that effect on my system (Debian Linux
64-bit) with dmd (latest git) and gdc (git gdc-4.7 branch). I always get
the same ordering regardless of the compiler I used.
For reference, here's my code:
import std.file;
import std.stdio;
void main(string[] args) {
auto entries = dirEntries(args.length 1 ? args[1] : .,
SpanMode.shallow);
foreach (e; entries) {
writeln(e);
}
}
T
--
Those who don't understand Unix are condemned to reinvent it, poorly.
Re: Sort order of dirEntries
On 10/25/2012 07:17 PM, H. S. Teoh wrote: Oh, really? I couldn't reproduce that effect on my system (Debian Linux 64-bit) with dmd (latest git) and gdc (git gdc-4.7 branch). I always get the same ordering regardless of the compiler I used. No, I think you're right; I'd been filtering dirEntries through takeExactly and it was generating an error using dmd. That reminds me -- did you tweak the GDC wiki to add the info about patching the GCC sources? I must get a working gdc-4.7 on my system.
GDC build [was: Re: Sort order of dirEntries]
On 10/25/2012 10:07 PM, H. S. Teoh wrote: No guarantees that it will work, though. The GCC build system is a fragile, sensitive animal. Indeed ... having followed your instructions (on 64-bit Ubuntu 12.10) I found myself first faced with the cannot find crti.o I'd encountered before. I fixed that by Alex Petersen's suggestion of symlinking /usr/lib/x86_64-linux-gnu/crt*.o to /usr/lib/crt*.o (which hopefully won't break anything) and the build proceeded on that basis, but finally fell over with another error, I think while trying to build gcov-dump (it's a bit hard to tell with such verbose compilation statements as GCC has): -- d/d-gcc.o: In function `used_arg': gcc.c:(.text+0xdf4): undefined reference to `fatal_error' d/d-gcc.o: In function `compare_version_strings': gcc.c:(.text+0xf4a): undefined reference to `fancy_abort' gcc.c:(.text+0xf5e): undefined reference to `fancy_abort' gcc.c:(.text+0xf6d): undefined reference to `fatal_error' gcc.c:(.text+0xf81): undefined reference to `fancy_abort' gcc.c:(.text+0xf90): undefined reference to `fatal_error' d/d-gcc.o: In function `version_compare_spec_function': gcc.c:(.text+0x1120): undefined reference to `fatal_error' gcc.c:(.text+0x1238): undefined reference to `fatal_error' gcc.c:(.text+0x124c): undefined reference to `fancy_abort' gcc.c:(.text+0x1258): undefined reference to `fatal_error' d/d-gcc.o: In function `compare_debug_auxbase_opt_spec_function': gcc.c:(.text+0x143c): undefined reference to `fatal_error' gcc.c:(.text+0x1448): undefined reference to `fatal_error' gcc.c:(.text+0x1454): undefined reference to `fatal_error' d/d-gcc.o: In function `xputenv': gcc.c:(.text+0x1762): undefined reference to `fnotice' d/d-gcc.o: In function `find_plugindir_spec_function': gcc.c:(.text+0x2497): undefined reference to `fancy_abort' d/d-gcc.o: In function `find_file_spec_function': gcc.c:(.text+0x24bb): undefined reference to `fancy_abort' d/d-gcc.o: In function `remove_outfile_spec_function': gcc.c:(.text+0x2532): undefined reference to `fancy_abort' d/d-gcc.o: In function `replace_outfile_spec_function': gcc.c:(.text+0x25dd): undefined reference to `fancy_abort' d/d-gcc.o: In function `getenv_spec_function': gcc.c:(.text+0x2677): undefined reference to `fatal_error' d/d-gcc.o: In function `process_command': gcc.c:(.text+0x2c62): undefined reference to `common_handle_option' gcc.c:(.text+0x2c71): undefined reference to `target_handle_option' gcc.c:(.text+0x2dda): undefined reference to `read_cmdline_option' gcc.c:(.text+0x2ffb): undefined reference to `warning' gcc.c:(.text+0x3111): undefined reference to `warning' gcc.c:(.text+0x322a): undefined reference to `fancy_abort' d/d-gcc.o: In function `retry_ice': gcc.c:(.text+0x381b): undefined reference to `fnotice' gcc.c:(.text+0x3b32): undefined reference to `fnotice' d/d-gcc.o: In function `add_sysrooted_prefix.constprop.20': gcc.c:(.text+0x3d72): undefined reference to `fatal_error' d/d-gcc.o: In function `init_spec.part.4': gcc.c:(.text+0x4184): undefined reference to `fnotice' d/d-gcc.o: In function `add_linker_option': gcc.c:(.text+0x4326): undefined reference to `vec_heap_p_reserve' d/d-gcc.o: In function `add_preprocessor_option': gcc.c:(.text+0x4386): undefined reference to `vec_heap_p_reserve' d/d-gcc.o: In function `add_assembler_option': gcc.c:(.text+0x43e6): undefined reference to `vec_heap_p_reserve' d/d-gcc.o: In function `driver_handle_option': gcc.c:(.text+0x4cde): undefined reference to `fancy_abort' gcc.c:(.text+0x4da9): undefined reference to `fancy_abort' gcc.c:(.text+0x4dbd): undefined reference to `fancy_abort' gcc.c:(.text+0x4dd1): undefined reference to `fancy_abort' gcc.c:(.text+0x4de5): undefined reference to `fancy_abort' d/d-gcc.o:gcc.c:(.text+0x4df9): more undefined references to `fancy_abort' follow d/d-gcc.o: In function `driver_handle_option': gcc.c:(.text+0x4e31): undefined reference to `fatal_error' d/d-gcc.o: In function `store_arg': gcc.c:(.text+0x4f8d): undefined reference to `vec_heap_p_reserve' d/d-gcc.o: In function `create_at_file': gcc.c:(.text+0x5214): undefined reference to `fatal_error' gcc.c:(.text+0x5223): undefined reference to `fatal_error' gcc.c:(.text+0x5232): undefined reference to `fatal_error' d/d-gcc.o: In function `execute': gcc.c:(.text+0x5666): undefined reference to `fatal_error' gcc.c:(.text+0x591c): undefined reference to `vec_heap_p_reserve' gcc.c:(.text+0x59b8): undefined reference to `vec_heap_p_reserve_exact' gcc.c:(.text+0x5e36): undefined reference to `fnotice' gcc.c:(.text+0x5f58): undefined reference to `fancy_abort' gcc.c:(.text+0x5f62): undefined reference to `fatal_error' gcc.c:(.text+0x5f8a): undefined reference to `fancy_abort' gcc.c:(.text+0x5fc1): undefined reference to `fatal_error' gcc.c:(.text+0x5fe4): undefined reference to `internal_error' gcc.c:(.text+0x5fee): undefined reference to `fatal_error' d/d-gcc.o: In function `do_spec_1':
Re: GDC build [was: Re: Sort order of dirEntries]
On Thu, Oct 25, 2012 at 11:08:48PM +0200, Joseph Rushton Wakeling wrote: On 10/25/2012 10:07 PM, H. S. Teoh wrote: No guarantees that it will work, though. The GCC build system is a fragile, sensitive animal. Indeed ... having followed your instructions (on 64-bit Ubuntu 12.10) I found myself first faced with the cannot find crti.o I'd encountered before. Oh? Did you run the debian/rules patch command in the package source directory? That was supposed to have fixed this issue, and potentially the issue you're seeing below (Debian-based systems break several assumptions that the GCC build system makese, so you really want to be applying the Debian patches to increase your odds of the build succeeding). I fixed that by Alex Petersen's suggestion of symlinking /usr/lib/x86_64-linux-gnu/crt*.o to /usr/lib/crt*.o (which hopefully won't break anything) and the build proceeded on that basis, but finally fell over with another error, I think while trying to build gcov-dump (it's a bit hard to tell with such verbose compilation statements as GCC has): Hmm. Frankly, I have no idea what's going on here. :-( I myself am facing an error where gdc git HEAD isn't building because Walter's .c C++ files are getting compiled with gcc, and failing horribly 'cos it's C++, not C. According to Iain, this isn't supposed to happen, but I still have no idea why it's happening. What parameters did you pass to configure? I wonder if you can turn off some stuff that you don't need, that might avoid this problem. I know that for me, I have to use --disable-multilib (at least), otherwise the build will fail. I also have --disable-gomp and --disable-quadmath, since neither are used by GDC. I'm not sure if they're related to your issue though. T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Re: GDC build [was: Re: Sort order of dirEntries]
On 10/25/2012 11:22 PM, H. S. Teoh wrote: Oh? Did you run the debian/rules patch command in the package source directory? That was supposed to have fixed this issue, and potentially the issue you're seeing below (Debian-based systems break several assumptions that the GCC build system makese, so you really want to be applying the Debian patches to increase your odds of the build succeeding). Yup. Latest gdc-4.7 sources (which I believe include your patch), GCC 4.7.2 sources from the Ubuntu 12.10 repositories, tweaked the debian/rules.patch file as instructed, ran the debian/rules clean and debian/rules patch functions and update-gcc.sh. I don't see anything in rules.patch that would get the compiler looking for crtio.o in /usr/lib/x86_64-linux-gnu/ though. What parameters did you pass to configure? I wonder if you can turn off some stuff that you don't need, that might avoid this problem. I know that for me, I have to use --disable-multilib (at least), otherwise the build will fail. I also have --disable-gomp and --disable-quadmath, since neither are used by GDC. I'm not sure if they're related to your issue though. Originally I tried with --enable-language=d --disable-multilib --enable-lto. I've since tried without the -lto option, and tried disabling all the parts that are not used by GDC (gomp, quadmath, etc.) Same error. :-( It's really very, very frustrating, especially when compared to how easy it is to build LDC from source. Even more so because it gets in the way of being able to actually help and contribute to GDC.
Re: GDC build [was: Re: Sort order of dirEntries]
On Fri, Oct 26, 2012 at 12:26:02AM +0200, Joseph Rushton Wakeling wrote: On 10/25/2012 11:22 PM, H. S. Teoh wrote: [...] Yup. Latest gdc-4.7 sources (which I believe include your patch), GCC 4.7.2 sources from the Ubuntu 12.10 repositories, tweaked the debian/rules.patch file as instructed, ran the debian/rules clean and debian/rules patch functions and update-gcc.sh. Hmm. I don't know what to say, it worked for me. :-/ I wonder if there's a difference between the Debian version of gcc-4.7.2 patches and Ubuntu's version. I doubt it, but you never know. That might be something worth looking into (you can add ftp.debian.org to /etc/apt/sources.list if you want to experiment with fetching the gcc sources from the Debian repository instead). Another thing I can think of is, you may need to run 'apt-get build-dep gcc-4.7.2' to install any -dev packages required by the build. That could be what's wrong. Maybe. I don't see anything in rules.patch that would get the compiler looking for crtio.o in /usr/lib/x86_64-linux-gnu/ though. The patches are in debian/patches/*. There's quite a lot of them; I didn't even bother looking through them. I wonder, though, if the Ubuntu sources don't have the multiarch patch? Try the upstream Debian package and see if that helps. What parameters did you pass to configure? I wonder if you can turn off some stuff that you don't need, that might avoid this problem. I know that for me, I have to use --disable-multilib (at least), otherwise the build will fail. I also have --disable-gomp and --disable-quadmath, since neither are used by GDC. I'm not sure if they're related to your issue though. Originally I tried with --enable-language=d --disable-multilib --enable-lto. I've since tried without the -lto option, and tried disabling all the parts that are not used by GDC (gomp, quadmath, etc.) Same error. :-( :-( Well, try apt-get build-dep gcc-4.7.2 and maybe fetch the source package from ftp.debian.org, and see if that helps. Beyond that, I'm afraid I don't know much else. GCC build scripts are black magic to me, of the blackest kind. It's really very, very frustrating, especially when compared to how easy it is to build LDC from source. Even more so because it gets in the way of being able to actually help and contribute to GDC. Yeah no kidding. Building GCC is one of the most frustrating experiences I've ever had with software compilation. There are just so many dependencies and assumptions (some unstated, or perhaps just stated in obscure places nobody knows where to look) about the build environment, system layout, etc., that it's a veritable fortress of cards ready to come all crashing down on you at the slightest wind. And often the error message is far removed from the location of the real problem, and gives you no clue at all as to what the real problem is. (That's why I said in another thread in the other forum that the GCC build scripts need to be revamped. Unfortunately, I doubt that will ever happen. :-/) T -- People walk. Computers run.
Re: GDC build [was: Re: Sort order of dirEntries]
On 10/26/2012 02:16 AM, H. S. Teoh wrote: Another thing I can think of is, you may need to run 'apt-get build-dep gcc-4.7.2' to install any -dev packages required by the build. That could be what's wrong. Maybe. Oh, good thought. Well, I did that, and went with the following configure statement: ../gcc-4.7-4.7.2/src/configure --enable-languages=d --disable-multilib --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libquadmath-support --enable-checking=release ... as I realized I'd left off the --enable-checking flag in previous builds. It now falls over in a different place again with the error: ../../gcc-4.7-4.7.2/src/gcc/graphite.c:50:19: fatal error: ppl_c.h: No such file or directory The patches are in debian/patches/*. There's quite a lot of them; I didn't even bother looking through them. I wonder, though, if the Ubuntu sources don't have the multiarch patch? Try the upstream Debian package and see if that helps. The following are present: gcc-multiarch.diff, gcc-multiarch-linaro.diff, gcc-multilib64-multiarch.diff, libjava-multiarch.diff, gcc-multiarch-doc.diff, gcc-multiarch-trunk.diff, gcc-multilib64-multiarch-trunk.diff :-( Well, try apt-get build-dep gcc-4.7.2 and maybe fetch the source package from ftp.debian.org, and see if that helps. Beyond that, I'm afraid I don't know much else. GCC build scripts are black magic to me, of the blackest kind. I'll give the Debian sources a go some time next week, maybe ...
Re: GDC build [was: Re: Sort order of dirEntries]
On Fri, Oct 26, 2012 at 02:50:08AM +0200, Joseph Rushton Wakeling wrote: On 10/26/2012 02:16 AM, H. S. Teoh wrote: Another thing I can think of is, you may need to run 'apt-get build-dep gcc-4.7.2' to install any -dev packages required by the build. That could be what's wrong. Maybe. Oh, good thought. Well, I did that, and went with the following configure statement: ../gcc-4.7-4.7.2/src/configure --enable-languages=d --disable-multilib --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libquadmath-support --enable-checking=release ... as I realized I'd left off the --enable-checking flag in previous builds. Hmm. Maybe try --enable-checking=yes? That's what I have. Though I'm not sure if this has anything to do with it. It now falls over in a different place again with the error: ../../gcc-4.7-4.7.2/src/gcc/graphite.c:50:19: fatal error: ppl_c.h: No such file or directory Hmm. Try apt-get install libppl0.11-dev, maybe? That's where that file should be. AFAIK apt-get build-dep should've pulled that one in, but just in case it didn't, this may help. The patches are in debian/patches/*. There's quite a lot of them; I didn't even bother looking through them. I wonder, though, if the Ubuntu sources don't have the multiarch patch? Try the upstream Debian package and see if that helps. The following are present: gcc-multiarch.diff, gcc-multiarch-linaro.diff, gcc-multilib64-multiarch.diff, libjava-multiarch.diff, gcc-multiarch-doc.diff, gcc-multiarch-trunk.diff, gcc-multilib64-multiarch-trunk.diff [...] OK, AFAIK this should be enough. But anyway, seems you've gotten a little farther now, so maybe it was the apt-get build-dep that was missing. Try installing libppl0.11-dev (or if that exact version isn't there, search for libppl*-dev in the Ubuntu archive) and see if that prods it along a bit more. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Re: Sort order of dirEntries
On Thu, Oct 25, 2012 at 02:15:06AM +0200, Joseph Rushton Wakeling wrote: Hello all, I've just been playing with dirEntries and by the looks of it, it returns these entries in arbitrary order. Is there a way to get it to sort the entries in alphabetical order, other than the obvious one of storing them in an array and sorting that? (This is untenable because I'm talking about a lot of files...:-) [...] This may not be possible if the OS doesn't keep the entries in sorted order (and from what I know, most OS's don't; it's only sorted upon display). *Somebody* will have to do the sorting, whether it's the OS, or the library or user code. The performance penalty will still be incurred regardless. T -- Don't drink and derive. Alcohol and algebra don't mix.
