www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - gdc-4.5 testing

reply Iain Buclaw <ibuclaw ubuntu.com> writes:
Just announcing (before I nod off) that gdc is working with gcc-4.5.1. Builds D1
and compiles Tango.

Commit:
https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa

Feedback, patches and bug reports welcome!

Regards
Dec 16 2010
next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Fri, 17 Dec 2010 00:41:12 +0000, Iain Buclaw wrote:


 Just announcing (before I nod off) that gdc is working with gcc-4.5.1.
 Builds D1 and compiles Tango.
 
 Commit:
 https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa
 
 Feedback, patches and bug reports welcome!
 
 Regards


Awesome, thanks for the effort! :)
Dec 17 2010
prev sibling next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Iain Buclaw wrote:


 Just announcing (before I nod off) that gdc is working with gcc-4.5.1. Builds
D1
 and compiles Tango.

 Commit:
 https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa

 Feedback, patches and bug reports welcome!


Says "This version of GCC () is not supported".
Missing a line for GCC 4.5 it seems, see patch.

Other than that, it seemed to apply cleanly to
Fedora 14's version of GCC (gcc-4.5.1-20100924)

--anders

PS. The "homepage" is still confused about
     how to use prefix and DESTDIR, it seems ?

     It should use --prefix=/opt/gdc, rather
     than --prefix=/usr/local and DESTDIR=/opt
Dec 17 2010
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Anders F Björklund (afb algonet.se)'s article

 This is a multi-part message in MIME format.
 --------------040104000201080008030306
 Content-Type: text/plain; charset=UTF-8; format=flowed
 Content-Transfer-Encoding: 7bit
 Iain Buclaw wrote:

 Just announcing (before I nod off) that gdc is working with gcc-4.5.1. Builds
D1
 and compiles Tango.

 Commit:
 https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa

 Feedback, patches and bug reports welcome!


 Says "This version of GCC () is not supported".
 Missing a line for GCC 4.5 it seems, see patch.
 Other than that, it seemed to apply cleanly to
 Fedora 14's version of GCC (gcc-4.5.1-20100924)
 --anders


Well, technically not "supported" yet, but I've added it, thanks! ;)
As coincidences goes, GCC-4.5.2 has just been released too. If anyone beats me
to it, please give that release a try first.



 PS. The "homepage" is still confused about
      how to use prefix and DESTDIR, it seems ?
      It should use --prefix=/opt/gdc, rather
      than --prefix=/usr/local and DESTDIR=/opt


I agree, DESTDIR rather archaic, and is only most useful if you are packaging
software.
But at the same time my natural unix instinct tells me to act alarmed at the
sight of suggesting --prefix=/opt/gdc. ;)
Dec 17 2010
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Iain Buclaw wrote:


 PS. The "homepage" is still confused about
       how to use prefix and DESTDIR, it seems ?
       It should use --prefix=/opt/gdc, rather
       than --prefix=/usr/local and DESTDIR=/opt


 I agree, DESTDIR rather archaic, and is only most useful if you are packaging
software.
 But at the same time my natural unix instinct tells me to act alarmed at the
sight of suggesting --prefix=/opt/gdc. ;)


So your instinct is fine with /opt/usr/local, but alarmed at /opt/gdc ?

I suppose you *could* use something like /usr/local/gcc-4.5 instead...

--anders
Dec 17 2010
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Anders F Björklund (afb algonet.se)'s article

 Iain Buclaw wrote:

 PS. The "homepage" is still confused about
       how to use prefix and DESTDIR, it seems ?
       It should use --prefix=/opt/gdc, rather
       than --prefix=/usr/local and DESTDIR=/opt


 I agree, DESTDIR rather archaic, and is only most useful if you are packaging
software.
 But at the same time my natural unix instinct tells me to act alarmed at the
sight of suggesting --prefix=/opt/gdc. ;)


 So your instinct is fine with /opt/usr/local, but alarmed at /opt/gdc ?


Oh, I didn't write the installation guide, so I'm not exactly fine with either
techniques. I've just haven't updated/removed it
because people would arguably complain that they can't easily remove gdc having
installed it in /usr/local.

I install gdc in ~/bin, because it's easier for me to handle (there is never
any need to elevate to root privileges), and there are
hooks in bashrc which auto-magically add it to my PATH.
Dec 17 2010
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Iain Buclaw wrote:


 I install gdc in ~/bin, because it's easier for me to handle (there is never
any need to elevate to root privileges), and there are
 hooks in bashrc which auto-magically add it to my PATH.


The only problem with ~/bin or ~/.local/bin is that for programs which 
are relocatable-challenged, they end up expanding it to an absolute path 
which makes harder to redistribute (i.e. having your user in it)
Other than that it is just fine. And the packages are using /usr anyway.

Can't ever have too many languages in there, it seems... :-P
     --enable-languages=c,c++,objc,objc-c++,d,java,fortran,ada,lto
 From http://pkgs.fedoraproject.org/gitweb/?p=gcc.git
      gcc-4.5.1-4.fc14.src.rpm

--anders
Dec 17 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Anders F Björklund (afb algonet.se)'s article

 Iain Buclaw wrote:

 I install gdc in ~/bin, because it's easier for me to handle (there is never




any need to elevate to root privileges), and there are

 hooks in bashrc which auto-magically add it to my PATH.


 The only problem with ~/bin or ~/.local/bin is that for programs which
 are relocatable-challenged, they end up expanding it to an absolute path
 which makes harder to redistribute (i.e. having your user in it)
 Other than that it is just fine. And the packages are using /usr anyway.
 Can't ever have too many languages in there, it seems... :-P
      --enable-languages=c,c++,objc,objc-c++,d,java,fortran,ada,lto
  From http://pkgs.fedoraproject.org/gitweb/?p=gcc.git
       gcc-4.5.1-4.fc14.src.rpm
 --anders


Yeah, emphasis on the *for me* bit. :)

Personally you should always use your systems package software to build from
source. It's better to have everything tracked rather than wondering around the
place, IMO. But the problem with that suggestion being it assumes people are
familiar with rpm-build, dpkg-source, etc...
Dec 17 2010
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
 Iain Buclaw wrote:



 Commit:
 https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa

 Feedback, patches and bug reports welcome!


 Says "This version of GCC () is not supported".
 Missing a line for GCC 4.5 it seems, see patch.

 Other than that, it seemed to apply cleanly to
 Fedora 14's version of GCC (gcc-4.5.1-20100924)


Not only applied, but also seems to be working... :-)
Once the enormous build and test completed, that is.

So now you can install both "ldc" and "gcc-d" (gdc),
and work with both Tango and Phobos from RPM packages.

$ cat hello.d
version (Tango)
import tango.io.Console;
else // Phobos
import std.stdio;

void main()
{
   version (Tango)
   Cout ("Hello, World!").newline;
   else // Phobos
   writefln("Hello, World!");
}

$ ldmd hello.d
$ ./hello
Hello, World!
$ gdmd hello.d
$ ./hello
Hello, World!

Will rebuild for Rawhide and post packages somewhere,
need to clean up the summaries and description a bit.

But that should make GDC available to Fedora as well,
or at least until they upgrade to GCC 4.6 that is...

* ldc
* tango (missing at the moment)
* tango-devel
* tango-static (missing at the moment)
* gdc
* phobos
* phobos-devel
* phobos-static

Good work!

--anders
Dec 18 2010
next sibling parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
i am a fedora packager i have already push into fedora repo
ldc,tango,mango,derelict i follow gdc project, for fedora they are a problem
gdc do not follow gcc upstream and is not yet a part of gcc
when gcc 4.7 comme into fedora how many time will be to wait for have
gdc/gcc4.7 ?
if gdc build with gcc 4.6 i coud try something but in perfect world gdc is a
gscc project.
Thanks for all, good works ;)
Dec 18 2010
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bioinfornatics (bioinfornatics fedoraproject.org)'s article

 i am a fedora packager i have already push into fedora repo


ldc,tango,mango,derelict i follow gdc project, for fedora they are a problem gdc
do not follow gcc upstream and is not yet a part of gcc

 when gcc 4.7 comme into fedora how many time will be to wait for have
gdc/gcc4.7 ?
 if gdc build with gcc 4.6 i coud try something but in perfect world gdc is a


gscc project.

 Thanks for all, good works ;)


And I'm a debian/ubuntu packager, which has the downside of me being very
centric
around their releases, rather than others.

If you really *need* gdc to be ported to gcc-4.6/trunk, I don't mind helping
where
questions or guidance are needed. Which is close enough to the same answer I
gave
to people asking when gdc will be ported to gcc-4.5.

In blunt terms though, I'd rather people joined in on the development.  :~)

Regards
Dec 18 2010
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
bioinfornatics wrote:

 i am a fedora packager i have already push into fedora repo
 ldc,tango,mango,derelict i follow gdc project, for fedora they are a
 problem gdc do not follow gcc upstream and is not yet a part of gcc


It's still possible to install gcc-d as an "add-on" to gcc,
if using the same compiler... One could of course install an
additional version of GCC, but it's smaller if just adding GDC.

For Ubuntu/Debian, GDC is available for the system compiler
so there you can just add D to the GCC Compiler Collection...
Fedora/Redhat could do that too, possibly using a compat gcc ?


 when gcc 4.7 comme into fedora how many time will be to wait for have
 gdc/gcc4.7 ? if gdc build with gcc 4.6 i coud try something but in
 perfect world gdc is a gscc project.


But Fedora 14 is currently running GCC version 4.5, though ?
Or you mean that it _will_ be a problem for new Fedora 15,
once that is released in about 6 month or so. Yeah, probably.

Of course, Fedora could help with porting GDC to 4.6 and on
if they want to include D with their supported languages ?
Even if GDC came *with* GCC, it would still need packaging...

--anders
Dec 18 2010
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Anders F Björklund (afb algonet.se)'s article

 Iain Buclaw wrote:

 Commit:
 https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa

 Feedback, patches and bug reports welcome!


 Says "This version of GCC () is not supported".
 Missing a line for GCC 4.5 it seems, see patch.

 Other than that, it seemed to apply cleanly to
 Fedora 14's version of GCC (gcc-4.5.1-20100924)


 Not only applied, but also seems to be working... :-)
 Once the enormous build and test completed, that is.
 So now you can install both "ldc" and "gcc-d" (gdc),
 and work with both Tango and Phobos from RPM packages.
 $ cat hello.d
 version (Tango)
 import tango.io.Console;
 else // Phobos
 import std.stdio;
 void main()
 {
    version (Tango)
    Cout ("Hello, World!").newline;
    else // Phobos
    writefln("Hello, World!");
 }
 $ ldmd hello.d
 $ ./hello
 Hello, World!
 $ gdmd hello.d
 $ ./hello
 Hello, World!


That's certainly nice to hear, considering the number of changes required were
considerably less than what was needed for gcc-4.4 (then again, many of them
were
backports from gcc-4.5 anyway ;). Of those changes made, they all turned out to
be
pretty quick/lazy edits.

Just preparing an update for 4.5.2 (and a strange segfault when building D2).
After that will begin the usual dstress/testsuite run against it to get an idea
of
just how production ready it is.

Regards
Iain
Dec 18 2010
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Iain Buclaw wrote:

 Other than that, it seemed to apply cleanly to
 Fedora 14's version of GCC (gcc-4.5.1-20100924)







 Not only applied, but also seems to be working... :-)
 Once the enormous build and test completed, that is.
 So now you can install both "ldc" and "gcc-d" (gdc),
 and work with both Tango and Phobos from RPM packages.





 That's certainly nice to hear, considering the number of changes required were
 considerably less than what was needed for gcc-4.4 (then again, many of them
were
 backports from gcc-4.5 anyway ;). Of those changes made, they all turned out
to be
 pretty quick/lazy edits.


I uploaded the packages to SourceForge, if anyone else
wants to try them... It's made for Fedora 14 (x86_64):

http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/


phobos-devel-4.5.1-4.fc14.x86_64.rpm (764K)

gcc-4.5.1-4.fc14.diff (3901 bytes, the specfile changes)
gcc-4.5.1-4.fc14.src.rpm (54M, but 5G+ / hours to build)

As noted earlier, LDC and Tango was already part of the
system release and are available in the yum repositories:

https://fedoraproject.org/wiki/Features/D_Programming

ldc-0.9.2-25.20101114hg1698.fc14.x86_64.rpm (4.1M)
tango-devel-0.99.9-19.20100826svn5543.fc14.x86_64.rpm (2.2M)

And then it's just a matter of running "gdmd" or "ldmd",
but if you want to use D2 you should still install "dmd":

http://www.digitalmars.com/d/2.0/changelog.html

http://ftp.digitalmars.com/dmd-2.050-0.i386.rpm

   ****

The GDC RPMs need to be built for i686, updated to 4.5.1-6 -
and adopted for inclusion in Rawhide, upgraded to GCC 4.6...

Most likely the imports should be moved to "include/d/4.5"
and libgphobos.a moved to inside "lib/gcc" directory, too ?

But that's up to Fedora packagers.

--anders
Dec 20 2010
next sibling parent reply Neal Becker <ndbecker2 gmail.com> writes:
Does this support building shared libs now (on x86_64)?

Anders F Björklund wrote:


 Iain Buclaw wrote:

 Other than that, it seemed to apply cleanly to
 Fedora 14's version of GCC (gcc-4.5.1-20100924)






 

 Not only applied, but also seems to be working... :-)
 Once the enormous build and test completed, that is.
 So now you can install both "ldc" and "gcc-d" (gdc),
 and work with both Tango and Phobos from RPM packages.




 

 That's certainly nice to hear, considering the number of changes required
 were considerably less than what was needed for gcc-4.4 (then again, many
 of them were backports from gcc-4.5 anyway ;). Of those changes made,
 they all turned out to be pretty quick/lazy edits.


 
 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):
 
 http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/
 

 phobos-devel-4.5.1-4.fc14.x86_64.rpm (764K)
 
 gcc-4.5.1-4.fc14.diff (3901 bytes, the specfile changes)
 gcc-4.5.1-4.fc14.src.rpm (54M, but 5G+ / hours to build)
 
 As noted earlier, LDC and Tango was already part of the
 system release and are available in the yum repositories:
 
 https://fedoraproject.org/wiki/Features/D_Programming
 
 ldc-0.9.2-25.20101114hg1698.fc14.x86_64.rpm (4.1M)
 tango-devel-0.99.9-19.20100826svn5543.fc14.x86_64.rpm (2.2M)
 
 And then it's just a matter of running "gdmd" or "ldmd",
 but if you want to use D2 you should still install "dmd":
 
 http://www.digitalmars.com/d/2.0/changelog.html
 
 http://ftp.digitalmars.com/dmd-2.050-0.i386.rpm
 
    ****
 
 The GDC RPMs need to be built for i686, updated to 4.5.1-6 -
 and adopted for inclusion in Rawhide, upgraded to GCC 4.6...
 
 Most likely the imports should be moved to "include/d/4.5"
 and libgphobos.a moved to inside "lib/gcc" directory, too ?
 
 But that's up to Fedora packagers.
 
 --anders
Dec 20 2010
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Neal Becker wrote:

 Does this support building shared libs now (on x86_64)?


...

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):

 http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/




You mean in general, or specifics ? (like throwing exceptions
or allocating memory or whatever...) Was it a problem before ?

Basic creation seems to work:

$ gdc -fPIC -o foo.o -c foo.d
$ gcc -shared -o libfoo.so foo.o
$ file libfoo.so
libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, not stripped

AFAIK both shared libraries and x86_64 code have been working
for years with GDC, even though that is not the case with DMD.

Phobos is still static, though.

--anders
Dec 20 2010
parent reply Neal Becker <ndbecker2 gmail.com> writes:
Anders F Björklund wrote:


 Neal Becker wrote:

 Does this support building shared libs now (on x86_64)?


 ...

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):

 http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/




 
 You mean in general, or specifics ? (like throwing exceptions
 or allocating memory or whatever...) Was it a problem before ?
 
 Basic creation seems to work:
 
 $ gdc -fPIC -o foo.o -c foo.d
 $ gcc -shared -o libfoo.so foo.o
 $ file libfoo.so
 libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
 dynamically linked, not stripped
 
 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.
 
 Phobos is still static, though.
 
 --anders


But you can't link shared obj to static lib (Phobos), except on i386 - so 
you really can't use shared obj on x86_64 (if you need phobos).
Dec 21 2010
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Neal Becker wrote:

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.

 Phobos is still static, though.


 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).


I don't get it, it shouldn't be that much different from a
static libstdc++ or something. You do need libgcc_s.so for
the exceptions to be thrown correctly, but otherwise your
application would be linking to Phobos anyway I thought...

Do you have some more advanced example than the toy tests ?

And it's possibly a *good* thing that Phobos is only a
static library, if it's not API/ABI-stable and ready...
It's easier to handle the code bloat than the dll hell.
But it does make for bigger executables than C++ does.

The size of the wxD executables was ridiculous, though. :-P

--anders
Dec 21 2010
parent reply Neal Becker <ndbecker2 gmail.com> writes:
Anders F Björklund wrote:


 Neal Becker wrote:

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.

 Phobos is still static, though.


 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).


 
 I don't get it, it shouldn't be that much different from a
 static libstdc++ or something. You do need libgcc_s.so for
 the exceptions to be thrown correctly, but otherwise your
 application would be linking to Phobos anyway I thought...
 
 Do you have some more advanced example than the toy tests ?
 
 And it's possibly a *good* thing that Phobos is only a
 static library, if it's not API/ABI-stable and ready...
 It's easier to handle the code bloat than the dll hell.
 But it does make for bigger executables than C++ does.
 
 The size of the wxD executables was ridiculous, though. :-P
 
 --anders


IIUC, the issue isn't exactly shared vs static lib, it's linking -fPIC code 
to a lib that is non-PIC code.  You can't link PIC code to non-PIC code 
except on i386.

http://www.technovelty.org/code/c/amd64-pic.html
Dec 21 2010
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Neal Becker wrote:

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.

 Phobos is still static, though.


 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).


 I don't get it, it shouldn't be that much different from a
 static libstdc++ or something. You do need libgcc_s.so for
 the exceptions to be thrown correctly, but otherwise your
 application would be linking to Phobos anyway I thought...

 Do you have some more advanced example than the toy tests ?





 IIUC, the issue isn't exactly shared vs static lib, it's linking -fPIC code
 to a lib that is non-PIC code.  You can't link PIC code to non-PIC code
 except on i386.

 http://www.technovelty.org/code/c/amd64-pic.html


Yeah, that was why the -fPIC was added to the DFLAGS in the test...

To avoid the linker error, when trying to make the shared library:
$ gcc -shared -o libfoo.so foo.o
/usr/bin/ld: foo.o: relocation R_X86_64_32 against `.rodata' can not be 
used when making a shared object; recompile with -fPIC

So I still don't get it.

--anders

PS. I put the toy test example code up, for reference:
     http://www.algonet.se/~afb/d/dsharedlibs.tar.gz
Dec 22 2010
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Neal Becker (ndbecker2 gmail.com)'s article

 Anders F Björklund wrote:

 Neal Becker wrote:

 Does this support building shared libs now (on x86_64)?


 ...

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):

 http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/




 You mean in general, or specifics ? (like throwing exceptions
 or allocating memory or whatever...) Was it a problem before ?

 Basic creation seems to work:

 $ gdc -fPIC -o foo.o -c foo.d
 $ gcc -shared -o libfoo.so foo.o
 $ file libfoo.so
 libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
 dynamically linked, not stripped

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.

 Phobos is still static, though.

 --anders


 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).



compiled as shared is because of inline asm clobbering the PIC register (EBX on
i386). Because we're not smart enough (LDC likely suffers from this also), in
some instances EBX can be wrongly marked as being clobbered too.

So things you can do to address this is:
1) Improve the inline asm. :~)
2) Hide all problematic places with version(D_PIC) in Phobos.
3) Turn off D_InlineAsm when flag_pic is turned on.
Dec 22 2010
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article

 == Quote from Neal Becker (ndbecker2 gmail.com)'s article

 Anders F Björklund wrote:

 Neal Becker wrote:

 Does this support building shared libs now (on x86_64)?


 ...

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):

 http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/




 You mean in general, or specifics ? (like throwing exceptions
 or allocating memory or whatever...) Was it a problem before ?

 Basic creation seems to work:

 $ gdc -fPIC -o foo.o -c foo.d
 $ gcc -shared -o libfoo.so foo.o
 $ file libfoo.so
 libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
 dynamically linked, not stripped

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.

 Phobos is still static, though.

 --anders


 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).



 compiled as shared is because of inline asm clobbering the PIC register (EBX on
 i386). Because we're not smart enough (LDC likely suffers from this also), in
 some instances EBX can be wrongly marked as being clobbered too.
 So things you can do to address this is:
 1) Improve the inline asm. :~)
 2) Hide all problematic places with version(D_PIC) in Phobos.
 3) Turn off D_InlineAsm when flag_pic is turned on.
Dec 22 2010
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Iain Buclaw wrote:

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.







 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).



 compiled as shared is because of inline asm clobbering the PIC register (EBX on
 i386). Because we're not smart enough (LDC likely suffers from this also), in
 some instances EBX can be wrongly marked as being clobbered too.


Ah, OK. That sounds like a different problem than "can't link"...
Does this also affect other shared libraries, without inline asm ?

Compiling Phobos as a shared library also seems to be a somewhat
different issue from compiling user D code as a shared library.

--anders
Dec 22 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Anders F Björklund (afb algonet.se)'s article

 Iain Buclaw wrote:

 AFAIK both shared libraries and x86_64 code have been working
 for years with GDC, even though that is not the case with DMD.


 But you can't link shared obj to static lib (Phobos), except on i386 - so
 you really can't use shared obj on x86_64 (if you need phobos).



 compiled as shared is because of inline asm clobbering the PIC register (EBX




on

 i386). Because we're not smart enough (LDC likely suffers from this also), in
 some instances EBX can be wrongly marked as being clobbered too.


 Ah, OK. That sounds like a different problem than "can't link"...
 Does this also affect other shared libraries, without inline asm ?


Nope, GCC produces code in such a way that this doesn't happen. As far as I'm
aware, only __asm__ statements can throw PIC-related compiler errors for reasons
I've already stated.


 Compiling Phobos as a shared library also seems to be a somewhat
 different issue from compiling user D code as a shared library.
 --anders


Seems related to me, from quote: "But you can't link shared obj to static lib
(Phobos)"
Dec 22 2010
prev sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Anders F Björklund wrote:


 Iain Buclaw wrote:

 Other than that, it seemed to apply cleanly to
 Fedora 14's version of GCC (gcc-4.5.1-20100924)






 

 Not only applied, but also seems to be working... :-)
 Once the enormous build and test completed, that is.
 So now you can install both "ldc" and "gcc-d" (gdc),
 and work with both Tango and Phobos from RPM packages.




 

 That's certainly nice to hear, considering the number of changes required
 were considerably less than what was needed for gcc-4.4 (then again, many
 of them were backports from gcc-4.5 anyway ;). Of those changes made,
 they all turned out to be pretty quick/lazy edits.


 
 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):


Thnx, installs and works fine for a few quick tests. Would be great to see 
the first D2 compiler in the next fedora release, and debian / ubuntu too of 
course. Great work!
Dec 20 2010
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Lutger Blijdestijn wrote:

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):


 Thnx, installs and works fine for a few quick tests. Would be great to see
 the first D2 compiler in the next fedora release, and debian / ubuntu too of
 course. Great work!


So that would be two different requests, the first is making
a new package for D2 and the second is upgrading to GCC 4.6...

https://fedoraproject.org/wiki/Features/GCC46

I believe that Ubuntu are sticking with GCC 4.5.x for Natty,
or at least 4.5.1 is what is in the current Alpha 1 release ?

http://packages.ubuntu.com/natty/gcc

The current "dmd" packages have an issue with /usr/bin/dmd
and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM,
even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't.
Any packages for GDC using D2 would have the same problem...

But it should be possible to use shims and symlinks to make
both installable, at least that's how it works on Mac OS X ?
A bigger problem is finding more developers for GCC46 and D2,
or perhaps upgrading LDC/Tango to D2 in the case of Fedora ?

--anders
Dec 21 2010
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Anders F Björklund wrote:


 Lutger Blijdestijn wrote:

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):


 Thnx, installs and works fine for a few quick tests. Would be great to
 see the first D2 compiler in the next fedora release, and debian / ubuntu
 too of course. Great work!


 
 So that would be two different requests, the first is making
 a new package for D2 and the second is upgrading to GCC 4.6...
 
 https://fedoraproject.org/wiki/Features/GCC46
 
 I believe that Ubuntu are sticking with GCC 4.5.x for Natty,
 or at least 4.5.1 is what is in the current Alpha 1 release ?
 
 http://packages.ubuntu.com/natty/gcc
 
 The current "dmd" packages have an issue with /usr/bin/dmd
 and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM,
 even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't.
 Any packages for GDC using D2 would have the same problem...
 
 But it should be possible to use shims and symlinks to make
 both installable, at least that's how it works on Mac OS X ?
 A bigger problem is finding more developers for GCC46 and D2,
 or perhaps upgrading LDC/Tango to D2 in the case of Fedora ?
 
 --anders


Yes, it requires some thought and manpower obviously. I'm not a packager, I 
don't what exactly is proper way to do it, but Fedora already packages 
python 2.x and python 3.x side by side, so perhaps that is a start. For 
Fedora I think D2 could be positioned as an alternative to mono in the long 
run, it fits the distro very well.
Dec 21 2010
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Lutger Blijdestijn (lutger.blijdestijn gmail.com)'s article

 Anders F Björklund wrote:

 Lutger Blijdestijn wrote:

 I uploaded the packages to SourceForge, if anyone else
 wants to try them... It's made for Fedora 14 (x86_64):


 Thnx, installs and works fine for a few quick tests. Would be great to
 see the first D2 compiler in the next fedora release, and debian / ubuntu
 too of course. Great work!


 So that would be two different requests, the first is making
 a new package for D2 and the second is upgrading to GCC 4.6...

 https://fedoraproject.org/wiki/Features/GCC46

 I believe that Ubuntu are sticking with GCC 4.5.x for Natty,
 or at least 4.5.1 is what is in the current Alpha 1 release ?

 http://packages.ubuntu.com/natty/gcc

 The current "dmd" packages have an issue with /usr/bin/dmd
 and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM,
 even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't.
 Any packages for GDC using D2 would have the same problem...

 But it should be possible to use shims and symlinks to make
 both installable, at least that's how it works on Mac OS X ?
 A bigger problem is finding more developers for GCC46 and D2,
 or perhaps upgrading LDC/Tango to D2 in the case of Fedora ?

 --anders


 Yes, it requires some thought and manpower obviously. I'm not a packager, I
 don't what exactly is proper way to do it, but Fedora already packages
 python 2.x and python 3.x side by side, so perhaps that is a start. For
 Fedora I think D2 could be positioned as an alternative to mono in the long
 run, it fits the distro very well.


In GCC you have give --program-suffix="foo" to give bespoke program suffixes to
the main driver name (gdc). This is usually used to identify different versions
of GCC, ie: gdc-4.4, gdc-4.5

Include directories need no altering, as we already install D2 files in
/usr/include/d2

Which leaves us with the name of the physical compiler (cc1d). This name is
constant for both D1 and D2 at the moment, though it's a one-liner change to
rename to "cc1d2" for D2 (see Make-lang.in), and you can have that in your
distribution patches.

Regards
Dec 21 2010
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Lutger Blijdestijn wrote:


 But it should be possible to use shims and symlinks to make
 both installable, at least that's how it works on Mac OS X ?
 A bigger problem is finding more developers for GCC46 and D2,
 or perhaps upgrading LDC/Tango to D2 in the case of Fedora ?


 Yes, it requires some thought and manpower obviously. I'm not a packager, I
 don't what exactly is proper way to do it, but Fedora already packages
 python 2.x and python 3.x side by side, so perhaps that is a start.


Well, that uses "python3" so by extension it would be using "d2" ?

It would also need some better way for packaging D programs than the 
current "BuildRequires: ldc". And portable $DFLAGS, e.g. -frelease

In https://fedoraproject.org/wiki/D+packaging+guideline+draft

But I don't know... It is soon 4 years since it (D) was originally
released and packaged for inclusion in Fedora (Core at the time) ?

It's always possible to install GDC or DMD manually, even if it is
not supported by your distribution. It just takes a bigger effort.
But it isn't _that_ much harder packaging GCC/GDC than DMC/DMD...
Even if it would be preferable to use the system gcc, if possible.

You *should* take it up with Fedora, if you want GDC to be included.


 For Fedora I think D2 could be positioned as an alternative to mono
 in the long run, it fits the distro very well.


I thought that Vala was already positioned as the alternative to Mono ?
At least when it came to writing GTK+ (and other GObject) applications.

But yeah, I was originally hoping on using D as an alternative to Java.

--anders
Dec 21 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Iain Buclaw wrote:

 Just announcing (before I nod off) that gdc is working with gcc-4.5.1. =


Builds D1

 and compiles Tango.
=20
 Commit:
 https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa
=20
 Feedback, patches and bug reports welcome!
=20


	I was unable to compile it (ArchLinux 64 bits). Apparently it fails
when building Phobos:


 mkdir -p gcc/config
 mkdir -p x86_64-unknown-linux-gnu/gcc/config
 touch stamp-tgtdir
 cp frag-ac x86_64-unknown-linux-gnu/gcc/config/config.d
 gcc -march=3Dk8-sse3 -O2 -pipe -g -Wall -I ../../../gcc-4.5.1-build/lib=


phobos/../include -c -o config/x3.o ../../../gcc-4.5.1-build/libphobos/co=
nfig/x3.c

 gcc: error trying to exec 'cc1': execvp: No such file or directory
 make[3]: *** [config/x3.o] Error 1
 make[3]: Leaving directory `/home/jerome/abs/gdc1-hg/src/gcc-build/x86_=


64-unknown-linux-gnu/libphobos'

 make[2]: *** [all] Error 2
 make[2]: Leaving directory `/home/jerome/abs/gdc1-hg/src/gcc-build/x86_=


64-unknown-linux-gnu/libphobos'

 make[1]: *** [all-target-libphobos] Error 2
 make[1]: Leaving directory `/home/jerome/abs/gdc1-hg/src/gcc-build'
 make: *** [all] Error 2
     Aborting...


	I tried going to the x86_64-unknown-linux-gnu/libphobos folder and
typing the failing gcc command manually, it fails too. Then I tried
going to that folder and compiling a simple hello world and I got
the same result (the hello world compiles fine in another folder).
Finally, I ran the command under strace and here is the relevant
part of the trace:


 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper", 0x7fff09=
206310) =3D -1 ENOENT (No such file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/lto-wrapper", 0x7fff09206310) =3D -1 ENOENT (No such =
file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unk=
nown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper", 0x7fff092=
06310) =3D -1 ENOENT (No such file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unk=
nown-linux-gnu/bin/lto-wrapper", 0x7fff09206310) =3D -1 ENOENT (No such f=
ile or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/cc1", 0x7fff09206230) =
=3D -1 ENOENT (No such file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/cc1", 0x7fff09206230) =3D -1 ENOENT (No such file or =
directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unk=
nown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/cc1", 0x7fff09206230) =3D=
 -1 ENOENT (No such file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unk=
nown-linux-gnu/bin/cc1", 0x7fff09206230) =3D -1 ENOENT (No such file or d=
irectory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/as", 0x7fff09206230) =3D=
 -1 ENOENT (No such file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/as", 0x7fff09206230) =3D -1 ENOENT (No such file or d=
irectory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unk=
nown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/as", 0x7fff09206230) =3D=
 -1 ENOENT (No such file or directory)

 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=


ibphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unk=
nown-linux-gnu/bin/as", 0x7fff09206230) =3D -1 ENOENT (No such file or di=
rectory)

 pipe([3, 4])                            =3D 0
 vfork(gcc: error trying to exec 'cc1': execvp: No such file or director=


y

 )                                 =3D 8557


	It appears that gcc looks for cc1 in the wrong location. It should
either take the system one
(/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/cc1) or one of those it
compiled itself (gcc/cc1  prev-gcc/cc1  stage1-gcc/cc1).

	The build was configured with:

 ../gcc-4.5.1/configure --prefix=3D/usr \
     --enable-languages=3Dd --enable-threads  --enable-__cxa_atexit \
     --disable-multilib --libdir=3D/usr/lib --libexecdir=3D/usr/lib \
     --disable-shared
 make


	I also tried adding C (--enable-languages=3Dc,d) to no avail.

		Jerome

PS: followups to D.gnu
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Dec 18 2010