Philip Van Hoof wrote:

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

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

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

> 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

Philip Van Hoof wrote:
> On Tue, 21 Mar 2006 18:36:07 -0800, Brad Roberts wrote:
> 
>> On Tue, 21 Mar 2006, clayasaurus wrote:
>>
>>> I wonder if anyone has ever seen this link? Sorry if it has been brought up
>>> before.
>>>
>>> http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html
>> Yup.. subject has been brought up several times.  The problem is to be integrated into the official gnu gcc source tree copyright has to be signed over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a draconian policy, but it's RMS's right to set those policies for software under the FSF umbrella no matter how much I think it hurts/sucks.
>>
>> Thankfully, building GDC out of tree like it is today is very very easy.
> 
> Yet it would be nice if it would be more easy to start using the compiler.
> Building it is for a lot programmers not really an option. Well, it should
> be but I guess most programmers are simply lazy.

The problem I had was that I couldn't find a short summary on how to do this, and so I wasn't exactly sure of the process.  But Thomas K's post here a while back helped a lot.  Still, it's a bit more complicated than simply choosing GDC from the package install tool and clicking a button.

> I'm planning to build packages for GDC on Fedora and Debian. Not that I
> know a lot about packaging. It would be, however, very useful to have a
> build procedure or package management or apt or yum source for GDC.
> 
> Perhaps I can convince people like Dag Wieers to host such a package on
> his repositories? I'll talk to Dag about it. I was thinking about creating
> a new .spec file (rather than patching for example the gcc4.spec file of
> for example Fedora).

This would be nice.


Sean

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

Philip Van Hoof 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 :(

"Almost works", I guess ? I know that 4.0.0 threw some fits,
but 4.0.1 has been working OK for the Mac builds at least...

I'll give your package a spin in a virtual FC4 environment, later.

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

You might be right, I've just used "c,c++,d" out of old habit.
I remember that it used to add the C++ automagically, though ?

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

AFAIK, the GDC patches are written by David Friedman and under
GPL with the copyright assigned over to the FSF already... ?

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

Definitely, I am using "Code::Blocks" (a wxWidgets-based environment)
and of course Xcode when not requiring any cross-platform or openness.

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

Using GDB for debugging, as it is integrated with the tools above.
However, GDB does need a little patching to understand D mangling.

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

I think you'll find that "Build" has assumed the role of that tool ?
I'm still using Makefiles, but that's a whole other story really...

--anders

On Wed, 2006-04-19 at 00:25 +0200, Anders F Björklund wrote:
> Philip Van Hoof 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 :(
> 
> "Almost works", I guess ? I know that 4.0.0 threw some fits, but 4.0.1 has been working OK for the Mac builds at least...
> 
> I'll give your package a spin in a virtual FC4 environment, later.

It looks like the problem has something todo with the changing of the vendor and version which the spec file does it try keeping the version exactly the same as the distribution compiler:

This part in the .spec file:

perl -pi -e 's/4\.0\.3/4.0.2/' gcc/version.c
perl -pi -e 's/"%{gcc_version}"/"%{gcc_version} \(release\)"/' gcc/version.c
perl -pi -e 's/\((prerelease|experimental|release|Red Hat[^)]*)\)/\(Red Hat %{version}-%{gcc_release}\)/' gcc/version.c

The code fails at an assertion that checks the version and vendor name the first time the xgcc compiler is used.

Philip Van Hoof escribió:
> On Tue, 2006-04-18 at 18:14 +0200, Anders F Björklund wrote:
>>
>> 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).

A ctags thing (whatever that is, I really don't know) has already be done. Maybe you can find it in the wiki.

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

Check DDT in DSource.

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

There's a gdb patch project in DSource, and there's some (a lot?) of information about debugging in the wiki.

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

Check Build in DSource. This is the defacto building tool for D.

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


-- 
Carlos Santander Bernal

On Wed, 2006-04-19 at 10:54 +0200, Philip Van Hoof wrote:
> On Wed, 2006-04-19 at 00:25 +0200, Anders F Björklund wrote:

Fixed

> perl -pi -e 's/\((prerelease|experimental|release|Red Hat[^)]*)\)/\(Red Hat %{version}-%{gcc_release}\)/' gcc/version.c

perl -pi -e 's/\((prerelease|experimental|release|Red Hat[^)]*)\)/\(Red Hat %{gcc_version}-%{gcc_release}\)/' gcc/version.c

You can find the result here:

http://pvanhoof.be/files/gdc-0.17-0.i386.rpm

Stuff like the source RPM and spec file: http://pvanhoof.be/files/gdc-package.tar.gz

Anders F Björklund schrieb am 2006-04-18:
> Philip Van Hoof wrote:
>
>> I'm planning to build packages for GDC on Fedora and Debian. Not that I know a lot about packaging. It would be, however, very useful to have a build procedure or package management or apt or yum source for GDC.
> ...
>> But if somebody wants to help or maybe if somebody already did such a package, tell me  ;-)
>
> Here is my RPM spec: http://www.algonet.se/~afb/d/gdc.spec This new version has quite a few options to choose from ?

<snip>

How about a "packages" project at dsource for a central repository of *.spec, *.ebuild and the like?

Thomas

Thomas Kuehne wrote:

> How about a "packages" project at dsource for a central
> repository of *.spec, *.ebuild and the like?

Brad said earlier he didn't have the space or bandwidth to host
the actual GDC packages, so I just put the make/spec files up...

http://www.algonet.se/~afb/d/Makefile [stuck at 0.10]
http://www.algonet.se/~afb/d/gdc.spec (being updated)

I also did packages for DMD, but since it's not distributable
it is all up to Walter - and he doesn't really like packages...

http://www.algonet.se/~afb/d/dmd.nsi [stuck at 0.146]
http://www.algonet.se/~afb/d/dmd.spec (being updated)


For the Gentoo ebuilds, they need to be in their "portage"
tree in order to be useful - but that's a political issue.
http://bugs.gentoo.org/show_bug.cgi?id=48136 (gdc)
http://bugs.gentoo.org/show_bug.cgi?id=46806 (dmd)
http://bugs.gentoo.org/show_bug.cgi?id=118209 (D)

I guess Debian has similiar issues in that it needs an
active maintainer to volunteer, and I don't know dpkg.
But someone making up a .DEB package would be neat,
since I think the same could be used for Ubuntu too ?
(Start Here: http://www.debian.org/doc/debian-policy/)


I've also considered doing a stand-alone "/opt" GDC package
with conservative settings, that would work on all distros.
(you would probably have to bundle it with GCC/G++/GDB too)

Maybe one could use something like http://autopackage.org/
or http://klik.atekon.de/ to deliver it for easy install ?
(i.e. making it similar to the Installers for Mac and Win)

There is also the possibility of bundling up a pre-compiled
"GDC toolkit" for MinGW and MSYS, for use with Windows too ?
Perhaps as a "DevPak" type of tarball ? http://devpaks.org/

There could be a /opt/gdc package, for each of the platforms.
(those would be: Windows with MinGW, Linux, Mac OS X / Darwin)
And then we could offer binaries for e.g. wxD to those as well ?


Coordinating the binary packages sounds like a very good idea.
Would be neat to have this and hosting, in place for GDC 0.18 ?
But I would want to wait for the feedback from David Friedman...

--anders

On Thu, 2006-04-20 at 09:50 +0200, Anders F Björklund wrote:
> Thomas Kuehne wrote:
> 
> > How about a "packages" project at dsource for a central repository of *.spec, *.ebuild and the like?
> 
> Brad said earlier he didn't have the space or bandwidth to host the actual GDC packages, so I just put the make/spec files up...


I have both the space and bandwidth for hosting such packages. I can also setup a virtual computer (Xen 3.0) for it. Please let me know if you need hosting assistance. As I like the D programming language, I'm not even planning to ask money for this service. But it would be nice to know the space requirements (as our disks aren't extremely large).

> http://www.algonet.se/~afb/d/Makefile [stuck at 0.10] http://www.algonet.se/~afb/d/gdc.spec (being updated)
> 
> I also did packages for DMD, but since it's not distributable it is all up to Walter - and he doesn't really like packages...

I finished a package that integrates with for example the gcc 4.0.2 package of Fedora Core 4.

This is the source stuff like the gcc 4.0.2 sources and the spec file:
    http://pvanhoof.be/files/gdc-package.tar.gz

> http://www.algonet.se/~afb/d/dmd.nsi [stuck at 0.146] http://www.algonet.se/~afb/d/dmd.spec (being updated)
> 
> 
> For the Gentoo ebuilds, they need to be in their "portage"
> tree in order to be useful - but that's a political issue.
> http://bugs.gentoo.org/show_bug.cgi?id=48136 (gdc)
> http://bugs.gentoo.org/show_bug.cgi?id=46806 (dmd)
> http://bugs.gentoo.org/show_bug.cgi?id=118209 (D)
> 
> I guess Debian has similiar issues in that it needs an
> active maintainer to volunteer, and I don't know dpkg.
> But someone making up a .DEB package would be neat,
> since I think the same could be used for Ubuntu too ?
> (Start Here: http://www.debian.org/doc/debian-policy/)

They are reusable for Ubuntu, indeed. But for example Dapper is already using gcc 4.1.x as default compiler, which afaik doesn't work with gdc at this moment. Same for Fedora Core 5.

> I've also considered doing a stand-alone "/opt" GDC package with conservative settings, that would work on all distros. (you would probably have to bundle it with GCC/G++/GDB too)
> 
> Maybe one could use something like http://autopackage.org/ or http://klik.atekon.de/ to deliver it for easy install ? (i.e. making it similar to the Installers for Mac and Win)
> 
> There is also the possibility of bundling up a pre-compiled "GDC toolkit" for MinGW and MSYS, for use with Windows too ? Perhaps as a "DevPak" type of tarball ? http://devpaks.org/
> 
> There could be a /opt/gdc package, for each of the platforms. (those would be: Windows with MinGW, Linux, Mac OS X / Darwin) And then we could offer binaries for e.g. wxD to those as well ?
> 
> 
> Coordinating the binary packages sounds like a very good idea. Would be neat to have this and hosting, in place for GDC 0.18 ? But I would want to wait for the feedback from David Friedman...

ok