D being talked about at gcc.gnu.org (RPM)

[Philip Van Hoof]

On Tue, 2006-04-18 at 18:14 +0200, Anders F Björklund wrote:

I tried transforming your spec file into one for specifically Fedora
Core 4. As Fedora Core 4 has a compiler (with updates installed it's gcc
4.0.2) that works with gdc.

I failed because I'm getting this internal compiler error :(. I don't
know why it's failing on me at that location. I tried with a lot
configure options. It didn't really make the problem go away (the
problem came later or earlier depending on what I enabled):

If you know what the problem might be, let me know. I might find a
solution myself. In that case I'll reply here. But I'm not a gcc
developer ... trying etc etc.



gcc   -O2 -g -march=i386 -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition    -DHAVE_CONFIG_H  -o gdc \
d/d-spec.o d/d-gcc.o version.o prefix.o
intl.o  ../libcpp/libcpp.a   ../libiberty/libiberty.a
echo
| /usr/src/redhat/BUILD/gcc-4.0.2-20051126/obj-i386-redhat-linux/gcc/xgcc -B/usr/src/redhat/BUILD/gcc-4.0.2-20051126/obj-i386-redhat-linux/gcc/ -B/usr/i386-redhat-linux/bin/ -B/usr/i386-redhat-linux/lib/ -isystem /usr/i386-redhat-linux/include -isystem /usr/i386-redhat-linux/sys-include -E -dM - | \
  sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \
        s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
  sort -u > tmp-macro_list
<built-in>:0: internal compiler error: in define__GNUC__, at
c-cppbuiltin.c:306
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
/bin/sh ../../gcc/../move-if-change tmp-macro_list macro_list
echo timestamp > s-macro_list
rm -rf include; mkdir include

And the final failure:

TARGET_CPU_DEFAULT="" \
HEADERS="ansidecl.h" DEFINES="" \
/bin/sh ../../gcc/mkconfig.sh tconfig.h
/usr/src/redhat/BUILD/gcc-4.0.2-20051126/obj-i386-redhat-linux/gcc/xgcc
-B/usr/src/redhat/BUILD/gcc-4.0.2-20051126/obj-i386-redhat-linux/gcc/
-B/usr/i386-redhat-linux/bin/ -B/usr/i386-redhat-linux/lib/
-isystem /usr/i386-redhat-linux/include
-isystem /usr/i386-redhat-linux/sys-include -O2 -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -I. -I. -I../../gcc
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include   -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer
\
   -c ../../gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o
<built-in>:1: internal compiler error: in define__GNUC__, at
c-cppbuiltin.c:306
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
make[1]: *** [crtbegin.o] Error 1
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-4.0.2-20051126/obj-i386-redhat-linux/gcc'
make: *** [all-gcc] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.24400 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.24400 (%build)
[root at zeus SPECS]#


I added the patches which are also applied to the FC4 gcc 4.0.2 version
and I've set the gcc version to a static define (rather than using the
gcc command to determine the version).

I extracted the gcc 4.0.2 source code and patches from the original FC4
gcc source package:

ftp://download.fedora.redhat.com/linux/updates/4/SRPMS/gcc-4.0.2-8.fc4.src.rpm


> > Also if you only do --enable-languages=d? I can imagine it will always
> > compile a c compiler, but will it also compile a c++ compiler? I noticed
> > you need a c++ compiler to compile gdc. That's why I added gcc-c++ as a
> > BuildRequires to that spec file of mine.
> 
> I believe that GDC shares the exception handling with the GNU C++ code ?
> It also used to share the GC with the GNU Java implementation, earlier.

I didn't have to enable the c and c++ languages for getting gdc
compiled. As I'm trying to build for the installed gcc compiler I'm
trying not to require building the c and c++ compiler. 

In this version c and c++ are enabled (but you can also disabled it from
the configure line):

http://pvanhoof.be/files/gdc-fc4-package-01.tar.gz

This is how I created that tar:

[root at zeus redhat]# tar zcvf gdc-fc4-package-01.tar.gz SOURCES/*patch
SOURCES/gcc-4.0.2-20051126.tar.bz2 SOURCES/gdc-0.17.tar.bz2
SPECS/gdc-fdo.spec
SOURCES/gcc4-gnuc-rh-release.patch
SOURCES/gcc4-ia64-libunwind.patch
SOURCES/gcc4-ia64-stack-protector.patch
SOURCES/gcc4-ice-hack.patch
SOURCES/gcc4-java-nomulti.patch
SOURCES/gcc4-ppc32-hwint32.patch
SOURCES/gcc4-ppc32-msecure-plt.patch
SOURCES/gcc4-ppc64-m32-m64-multilib-only.patch
SOURCES/gcc4-stack-protector.patch
SOURCES/gcc4-weakref.patch
SOURCES/gdc-fdo4.patch
SOURCES/gcc-4.0.2-20051126.tar.bz2
SOURCES/gdc-0.17.tar.bz2
SPECS/gdc-fdo.spec
[root at zeus redhat]#

Note the gdc-fdo4-patch, which is a patch that removes the function.h
patch from the original gdc patch for gcc-4.0 and patches that same
function.h file itself correctly.

The spec file will after that patching magic launch the setup-gcc.sh
script.


> > We can patch the sources of the gcc exactly how the distributors did it.
> > Would that make it match the C/C++ compiler *perfectly*?
> 
> Well, just as long as you can link a D component created with "gdc"
> to a C/C++ component compiled with "gcc" - it's close enough to count ?
> 
> > I understand that including gdc with the mainstream gcc code isn't (yet)
> > an option: After reading the newsgroups, I understood there where some
> > licensing issues like the FSF requiring copyright reassignment? It's
> > really a pity issues like that make it harder for developers who'd like
> > to tryout gdc.
> 
> I think what we could be aiming for is to include the *patches* into 
> GCC, and provide the D front-end and the Phobos library as add-ons ?

Right. Sounds like the best solution. I wonder whether both the GCC
developers and the authors of the GDC patches are interested in
cooperating here? For example, are the authors of the GDC patches
interested in reassigning the copyright to the FSF? And is the FSF
interested in maintaining the changes?


> > The best solution would be, of course, to simply build against the gcc
> > of the distribution and try to get a perfect match (if such a perfect
> > match is required).
> 
> Yes, that it's the preferred solution if it works. I was (eventually) 
> able to do so on Mac OS X, by bringing a few Apple changes over as 
> patches to the FSF tree. For Fedora, it's about finding the patches...
> (you only want the ones that affect features and binary compatibility)
> 
> > My personal story is that if the language would be a little bit more
> > used (popular), I could more easily sell it to my employer as a usable
> > programming environment. Packages would be a good start.
> 
> Yes, sounds like a good start... I'm also working on the other missing 
> components, namely a development environment (IDE) and a user interface.
> And me and my company is investing heavilly in making it more popular,
> even if met with mixed success so far... But maybe one day it will be ?

Existing development environments can be reused. Creating a ctags-like
(dtags) for d isn't going to be very hard and would enable things like
code completion on for example Anjuta. I think the code completion of
MonoDevelop uses some specific Mono/C# things (so that one probably
ain't an option).

Other than that would support for the D language in gnome-build be
useful. Adding that support would basically enable Anjuta as development
environment for D on the GNOME desktop.

Creating a plugin for Eclipse like CDT also sounds like a good option.

And then you have debugger integration, of course. I don't know how hard
that would be.

Integration with autotools (like, m4 macro's for detecting the compiler
and setting compiler flags correctly) might also be important. Or create
a dant (like nant and ant but then for d).

But I agree that all these vague ideas mean: lots of work todo.


> > It would also be more easy for packagers to build my softwares, if a
> > packaged compiler would exist. The packagers in our communities really
> > dislike having to compile a compiler before they can create a package of
> > our software. Most of the packager communities have automated package
> > building environments that will automatically test and compile for all
> > supported architectures. You don't want to require them to compile a
> > compiler in /opt/gdc ;-). They wont package your software.
> 
> The advantage of doing a vanilla GCC/G++/GDC compiler in /opt/gdc, is 
> that you don't have to rely on the package monkey of the DistroDuJour 
> but that you can use one self-contained compiler package for all...
> 
> The downside is that GDC is like 3 MB, while GCC/G++/GDC is like 30M ?
> (not to mention having to re-compile all the libraries you want to be 
> using, just because C++ isn't link-compatible between versions, etc.)


> In theory the spec file I have can be used, if the system compiler is
> of a usable version (i.e. not too old like RH 7 nor too new like FC 5)
> 
> But you still need one RPM for each distro version, which is a pain...
> However, if the build is able to be automated - it can be lived with ?
> 
> --anders