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:
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 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!

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


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


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

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

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

 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)

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/ gcc-d-4.5.1-4.fc14.x86_64.rpm (5.2M) # gdc 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/ gcc-d-4.5.1-4.fc14.x86_64.rpm (5.2M) # gdc 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.

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.

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.

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

you really can't use shared obj on x86_64 (if you need phobos).

As far as I'm aware, the #1 reason why (for GDC, at least) Phobos can't be 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

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.

Reason #2, IMO, extern(C) main should **not** be in a shared library. :~)
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).

As far as I'm aware, the #1 reason why (for GDC, at least) Phobos can't be 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.

you really can't use shared obj on x86_64 (if you need phobos).

As far as I'm aware, the #1 reason why (for GDC, at least) Phobos can't be compiled as shared is because of inline asm clobbering the PIC register (EBX


 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.

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

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 ?

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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

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

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=

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_=

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

 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=

206310) =3D -1 ENOENT (No such file or directory)
 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=

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

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=

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=

=3D -1 ENOENT (No such file or directory)
 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=

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

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=

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=

-1 ENOENT (No such file or directory)
 stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/l=

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

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=

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=

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