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.

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 ...

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

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 ... :-\

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.

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).