Re: gdc-4.5 testing
== Quote from Anders F Björklund (a...@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). > > > > 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 ? 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)"
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
== Quote from Iain Buclaw (ibuc...@ubuntu.com)'s article > == Quote from Neal Becker (ndbeck...@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). > 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. Reason #2, IMO, extern(C) main should **not** be in a shared library. :~)
Re: gdc-4.5 testing
== Quote from Neal Becker (ndbeck...@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). 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.
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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).
Re: gdc-4.5 testing
== Quote from Lutger Blijdestijn (lutger.blijdest...@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
Re: gdc-4.5 testing
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.
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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!
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
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!
>
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=k8-sse3 -O2 -pipe -g -Wall -I
> ../../../gcc-4.5.1-build/libphobos/../include -c -o config/x3.o
> ../../../gcc-4.5.1-build/libphobos/config/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/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> pipe([3, 4])= 0
> vfork(gcc: error trying to exec 'cc1': execvp: No such file or directory
> ) = 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=/usr \
> --enable-languages=d --enable-threads --enable-__cxa_atexit \
> --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib \
> --disable-shared
> make
I also tried adding C (--enable-languages=c,d) to no avail.
Jerome
PS: followups to D.gnu
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
== Quote from bioinfornatics (bioinfornat...@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
Re: gdc-4.5 testing
== Quote from Anders F Björklund (a...@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
Re: gdc-4.5 testing
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 ;)
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
== Quote from Anders F Björklund (a...@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...
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
== Quote from Anders F Björklund (a...@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.
Re: gdc-4.5 testing
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
Re: gdc-4.5 testing
== Quote from Anders F Björklund (a...@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. ;)
Re: gdc-4.5 testing
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
--- gdc/d/setup-gcc.sh.orig 2010-12-17 01:35:16.0 +0100
+++ gdc/d/setup-gcc.sh 2010-12-17 10:03:22.553769631 +0100
@@ -56,6 +56,8 @@
gcc_ver=4.3
elif grep -q '^4\.4\.' gcc/BASE-VER; then
gcc_ver=4.4
+elif grep -q '^4\.5\.' gcc/BASE-VER; then
+gcc_ver=4.5
fi
gcc_patch_key=${gcc_ver}.x
Re: gdc-4.5 testing
On Fri, 17 Dec 2010 00:41:12 +, 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! :)
gdc-4.5 testing
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
