d-language-packagers team mailing list archive

[Vincenzo Ampolo <vincenzo.ampolo@xxxxxxxxx>]

On Tuesday 16 December 2008 12:56:02 Markus Mahlberg wrote:
> I would not take this as granted. Actually this bug seems to be invalid for
> intrepid (at last I can compile the code mentioned AND run it.)

As reported in the bug at comment 4 and tested again right now to verify your 
words:

goshawk@earth:~$ gdc-4.2 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,d --prefix=/usr --
enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-
gettext --enable-threads=posix --enable-nls --with-gxx-include-
dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --disable-
libmudflap --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-
linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 20080705 (prerelease gdc 0.25 20080312, using dmd 1.024) 
(Ubuntu 0.25-4.2.4-3.1)
goshawk@earth:~$ cat test.d
import std.stdio;
  void main() {
      writefln("Hello %s!", "world");
  }
goshawk@earth:~$ gdc-4.2 test.d
goshawk@earth:~$ ./a.out
Segmentation fault
goshawk@earth:~$

GDC is broken on x86_64 and there is no fix right now and i don't think we will 
see a fix soon. In x86 there are no problems of course.

Please trust me if you wanna collaborate with me. And if you think that i say 
nonsense please show me "code" and "facts" not words.

> That is only partially true. As mentioned earlier, you could use file
> diversions (as shown in Appendix G of the debian policy manual at
> http://www.debian.org/doc/debian-policy/ap-pkg-diversions.html)

Yes.. it can be good "for now" but i don't think that a library package which 
has a diversion conflict with the compiler will be accepted in the archive.

>
> From my point of view gdc is the only compiler suitable for integration
> into Ubuntu and/or Debian at this very moment, reason's follow.

Is the same for me...

> There is huge effort put into gdc support atm from the tango project
> side. But I agree that probably the best way would be to pursuit a
> different compiler, the favourite of most seems to be ldc.
> I already filed 2 ITP (ldc and libtango) at Debian BTS.

Good, but i don't like the llvm arch so i'll not use it happily. This is wh my 
focus is on gdc and gcc backend.

>
> There are some problems though: Since llvm-2.4 is experimental at
> Debian, ldc has to be experimental too, along with libtango (if
> dependent on ldc). This basically means 1 and a half year until stable
> could be reached.

This is one of the main problems of llvm. :)

>
> To spread the word of D and tango, I'd suggest creating an unstable
> package for both libtango and dsss which is dependent on gdc, along with
> a source package to be able to use libtango even if one does not want to
> use the dsource repo. For those not knowing: dmd can not be distributed
> via the official repositories due to it's license.

There is  table package yet for dsss that has no lintian error and it build on 
x86 x86_64 and lpia.
It's on REVU and on PPA. It has been ported on 0.78 as you suggested 
https://launchpad.net/~d-language-packagers/+archive

The same for libtango, in the same repo there is a libtango package with no 
fails that contains libgphobos.a and object.di as Lars said.

They are both there, ready, please have a look.

>
> Additionally, experimental packages can be created for ldc and libtango
> dependent on ldc.

Sorry but i'm not interested on them.
You can use our PPA and our repo for it of course, but i'm focusing on gdc 
right now (+ work + studies + girlfriend).

>
> Since I have filed ITP for both ldc and libtango, I suggest we combine
> our efforts in a way that you maintain the gdc part and I maintain the
> ldc part. That would reduce friction a lot (and make both your and my
> life easier).

I agree.
Trust me and we can start working together in the same repo.
Are you tomorrow on irc? i'll be there so we can talk and i can explain the 
libtango package internals.

Mind that the published package is build like an application, it works, but of 
course it's not standard and it's a package that fits the "KISS" philosophy 
that we like ;)

The one under development in bzr instead is building with Policy in mind and 
as a library and it's BROKEN for now. 

Best Regards
-- 
Vincenzo Ampolo
http://vincenzo-ampolo.net

Attachment: signature.asc
Description: This is a digitally signed message part.