On 09/25/13 10:20, Bruno Medeiros wrote:
> I mean, there will be up-to-date precompiled Windows releases, right?
It's my intention. I'd like to get an automated process setup so that
new builds can be generated automatically.
Though, Windows isn't so friendly for that type of work when it comes
On 09/23/13 14:00, Bruno Medeiros wrote:
> (Is the TDM version correct/compatible?
No, you're mixing GCC 4.7.1(TDM) with GCC 4.6.1 (GDC). It's also using
an older version of D.
> Is the x64 version of TDM/GDC significantly ahead of the 32 bits one?
Not that I'm aware of, what really matters with
On 04/03/2013 05:44 PM, Jack Applegame wrote:
> Which version of MinGW did you use for compilation? TDM/MinGW-w64 or
> something else?
>
> I consider MinGW-builds (http://sourceforge.net/projects/mingwbuilds/)
> is the best MinGW pack.
>
I used standard MinGW http://mingw.org for compilation. It
Forgot GIT instructions.
For GDC, you can clone the Master branch. You'll have to manually
specify which commit.
git clone https://github.com/D-Programming-GDC/GDC.git
git checkout 166e02c2e99c3f6926513bb617593f24b7f4456f
Apply patch mingw-gdc.patch
I got GDC working with GCC 4.8 on MinGW. You can find it at
https://bitbucket.org/goshawk/gdc/downloads/GCC-4.8-MinGW-GDC-.7z
A couple of notable things. It's ALPHA quality. If it works, you're
lucky. You'll find regressions. The patches required to fix some of
the past bugs haven't been
On 3/15/2013 11:42 AM, Benjamin Thaut wrote:
Well mingw-gdc is quite a bit behind.
I'm working on that.
C:\MinGW\msys\1.0>/crossdev/gdc/stage/bin/gdc -v
Using built-in specs.
COLLECT_GCC=/crossdev/gdc/stage/bin/gdc
COLLECT_LTO_WRAPPER=c:/crossdev/gdc/stage/bin/../libexec/gcc/i686-pc-mingw32/4.
On 3/10/2013 12:08 PM, Benjamin Thaut wrote:
>> So now it actually compiles all the way through, but failes while
>> linking:
>>
>> C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible
>>
C:/crossdev/gdc64/v2/build/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs\libstdc++.a
>
I managed to exactly reproduce the error by setting gcc/d/lang.opt to
CRLF line endings.
You need to make sure everything is LF line endings. I've set a
.gitattributes file which hopefully will fix this for future checkouts.
On 3/9/2013 5:06 AM, Benjamin Thaut wrote:
Ok, the new build script solved a lot of issues. Unforunately the
multiline-stirng issue in options.c remains. Are you sure that you are
not using a 3.x.x gcc?
If you follow the build script you'll see it extracts the TDM 4.6.1
binary and forces that du
I've pushed updates that fix the sqlite issue as well as a few other
minor adjustments to the build process.
I'll look into the tlssup.c.patch issue soon.
On 3/8/2013 5:55 AM, Benjamin Thaut wrote:
So I completely reinstalled MinGW. Now the patch correctly applies, but
now make will freeze in
The crossdev directory is important because GCC is being called natively
and it allows paths to match up.
Otherwise /crossdev becomes /mingw/msys/1.0/crossdev which causes all
sorts of mayhem. That said, as long as you are building on F:\ it there
shouldn't be an issue.
On 3/6/2013 2:55 PM,
On 3/6/2013 12:45 PM, Benjamin Thaut wrote:
Well I did compile 0.11. I just used your build-tdm-gcc.sh which
downloads and compiles 0.11. I fixed this issue by opening
crossdev\src\ppl-0.11\Watchdog\src\pwl.hh.dist and setting
PWL_HAVE_DECL_SETITIMER to 0.
That shouldn't be necessary. It may hav
On 3/5/2013 2:02 PM, Benjamin Thaut wrote:
Ok I just tested it with vanialla mingw, same problem itimerval is not
defined in any of the mingw headers and thus compilation of ppl will fail.
It looks like a configuration issue when compiling PPL. itimerval looks
POSIX only.
Which version did
On 3/4/2013 12:49 PM, Benjamin Thaut wrote:
when building ppl I get the error message "'itimerval' does not name a
type". Is this a known issue too?
I don't believe I've ran into that specific problem. What more can you
tell me about the build environment/error generated?
On 2/26/2013 6:29 PM, Vladimir Panteleev wrote:
Are the instructions at http://gdcproject.org/wiki/MinGW64 up to date?
I noticed it mentions some patches attached to a BitBucket ticket, but
the ticket now points to a patch queue, and GDC development had since
moved to GitHub.
The instructions a
On 1/12/2013 5:37 PM, Vladimir Panteleev wrote:
By the way, I noticed this in README-gdc-mingw.txt:
Includes D1 and D2 compilers. Defaults to D1,
D2 can be used by specifying -v2.
-v2 must be used if GDC is used for linking.
And in the gdmd perl script:
} elsif ( $arg =~ m/^-v1$/ ) {
A new binary has been posted. This contains GDC master up to Nov. 28th.
There's one annoyingly significant bug that I am aware of regarding
exceptions.
Any uncaught exceptions will result in an infinite loop eventually
dieing due to stack overflow. However, this is only a minor annoyance
a
On 11/28/2012 6:59 AM, js.mdnq wrote:
I'll assume that for future reference the gdc's gcc version must always
must the tdm's version to avoid these types of issues. Please correct me
I'm wrong.
That's correct. At some point, it's possible I may release GDC
standalone from TDM. When that happ
Are you using the 64-bit version of TDM? This usually gets installed
into c:\MinGW64 but you mention that you copied the files into
c:\MinGW32 .
The error can also indicate that the DLL is missing exported functions
required by the executable.
I've encountered the same error when mixing the
On 11/27/2012 6:37 AM, js.mdnq wrote:
I'm trying to test gdc for Win/x64, I too get the same errors about
missing dll's.
This was my process:
1. Install tdm64-gcc-4.7.1-3.exe
2. Extract gcc-4.6.1-tdm64-1-gdc-20121117-D2.060.7z to the MinGW64
install dir.
You will need to use the gcc-4.6.1 ver
My best guess, is the issue is related to the struct being 4 bytes.
A similar segfault occurs if you attempt to access in a similar manner
using c++.
A 4 byte struct will fit into a single register making pointers
unnecessary/slower and it's likely some part of the ABI has taken this
into con
On 8/13/2012 9:42 PM, Andrej Mitrovic wrote:
> The command in console is:
>
> gdc -m32 -I./out/d -I.. -c ./out/d/TagLib/TrueAudio/TrueAudio.d -o
> bin/wrap_d___out_d_TagLib_TrueAudio_TrueAudio.o
>
> and in a D script which ICEs:
> system(r"gdc -m32 -I./out/d -I.. -c
> ./out/d/TagLib/TrueAudio/True
What's New
* ClassInfo uses export attribute. This allows the use of classes with
Dlls. https://bitbucket.org/goshawk/gdc/issue/352
* Corrects 64bit COM issues. https://bitbucket.org/goshawk/gdc/issue/355
Features
* D2.058
* binutils with TLS patches
* mingw-w64-runtime with TLS and stdi
What's New
* Support for Fibers. https://bitbucket.org/goshawk/gdc/issue/342/
* Unoptimized cc1d.exe and libphobos for better debugging.
Features
* D2.058
* binutils with TLS patches
* mingw-w64-runtime with TLS and stdio fixes.
* GCC 4.6.1 with TLS patches
Due to the use of a newer runti
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Due to the use of a newer runtime than TDM64-GCC it is **recommended**
to install a copy specifically for GDC.
Features
**ALPHA** As in, D2.058 support is still new.
* D2.058
* Debug information available us
On 5/1/2012 1:53 AM, Iain Buclaw wrote:
no _Dmodule_ref would probably mean no object_.d was compiled in.
In D2.058, the _Dmodule_ref code was moved to minfo.d. I didn't
properly move the GNU specific stuff on the first build, problem didn't
surface until I compiled it with MinGW.
They red
On 4/30/2012 2:49 PM, Manu wrote:
I also built sqlite, but it's complaining with lots of:
C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB6AttachMFAxaAxaZE4demu5tools5error9ErrorCode':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:57: u
On 4/30/2012 6:18 AM, Manu wrote:
I guess the etc.c... libs didn't make the cut :(
It was sort of an intermittent release, to get it out and tested.
To update the lib status, zlib is already part of libgphobos2.a. If you
inspect the library you'll see it's object files. If you're having
sp
Removed the download. Broken binaries aren't useful.
Try
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-7e1a98da2769-20120428-D2.058.7z
** Fixes, previous unresolved _Dmodule_ref **
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Due to the use of a newer runtime than TDM64-GCC it is **recommended**
to install a copy specifically for GDC.
Features
**ALPHA** As in, D2.058 support is still
On 4/27/2012 1:58 PM, Dmitry Olshansky wrote:
Before I try to workaround this beast anyone have an idea what's wrong?
In a nutshell, MinGW has a strange existence between the Posix code and
Windows code. So, it's often affected by changes in both.
Windows handles modules differently than GD
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Due to the use of a newer runtime than TDM64-GCC it is **recommended**
to install a copy specifically for GDC.
Features
**ALPHA** As in, D2.058 support is still new.
* D2.058
* Debug information available us
Hello Andrej,
On 4/23/2012 12:02 PM, Andrej Mitrovic wrote:
Hey Daniel,
I've tried your new mingw-gdc repository but I've had some patching failures:
$ hg qclone https://bitbucket.org/venix1/mingw-gdc
$ cd mingw-gdc
$ hg qpush -a
The new steps are(roughly):
# Requires hg-git
hg clone git://
On 4/17/2012 9:44 AM, Joseph Rushton Wakeling wrote:
Shall I make a new bug report? Is it preferred at BitBucket or GitHub?
Please do. We're still using BitBucket at the moment.
On 4/6/2012 8:00 AM, Joseph Rushton Wakeling wrote:
In fact, the zipped-up wscript is contained within the build script as a
binary blob, no? This alone is enough to make it fall under the GPL
provisions.
An interesting thing to note about the waf binary blob. Currently, it
actually extracts
My votes on waf. So I think I'll share my experiences with it.
Several years ago I wanted a cross platform solution to handling project
builds. I had been using eclipse/CodeBlocks which worked OK for simple
project but the lack of binary libraries for D and Windows combined made
me desire so
On 3/29/2012 1:34 PM, Marco Leise wrote:
As the topic suggests, I'm looking for instructions to get a cross-compiler
working on Linux and the ones in the Wiki are fairly outdated, referring to old
versions of D2 and GCC.
The compiler actually builds, but it cannot build Phobos, with these line
On 3/25/2012 5:10 AM, Manu wrote:
Are there work arounds if I should happen to run in to this? GDC is
currently the only win64 compiler. I'm putting a lot of faith it in for
the time being.
Until it's found why it happens, I can't say how to avoid it. Roughly I
think it may be related to the
On 3/24/2012 8:35 PM, Manu wrote:
> Cheers for the info. Here's hoping the release works out well.
> What instabilities are you primarily concerned about with the existing
> release? I've been using it for a couple of weeks, and had no problems.
> Are there particular things you anticipate causing
able long term. I really have no interest in
maintaining a fourth MinGW installer(mingw, mingw-w64, TDM).
Best Regards,
Daniel Green
On 2/16/2012 3:25 PM, Andrew Wiley wrote:
Trouble is that this a few thousand line codebase. I'll see what I can
do about getting a reduced sample.
If I can get a copy I'll look at it when I have some free time. A
reduced case helps tremendously but isn't necessary.
I was mostly wondering whe
8:46 AM, Daniel Green wrote:
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Due to the use of a newer runtime than TDM64-GCC it is **recommended** to
install a copy specifically for GDC.
Features
* binutils with TLS patches
* mingw-w64-runtime with TLS
On 1/30/2012 5:34 AM, Sönke Ludwig wrote:
Most cases work for me now. Only the LoadLibrary+DllMain tests still produce a
status 988 (access violation in dll_process_attach...dll_fixTLS or
rt.lifetime.__getBlkInfo if Runtime.initialize is used instead). It also links
now
without the manual _tls_
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Due to the use of a newer runtime than TDM64-GCC it is **recommended**
to install a copy specifically for GDC.
Features
* binutils with TLS patches
* mingw-w64-runtime with TLS and stdio fixes.
* GCC 4.6.1 w
All tests pass. However, I see your problem.
In plaindll.d:
version(GNU){ // Workaround for linker error
void* _tlsstart; // First symbol of the TLS section
void* _tlsend;
//int _tls_callbacks_a; // Workaround for GDC/MinGW linker error
}
_tlsstart is the first symbol o
On 1/26/2012 11:01 AM, Sönke Ludwig wrote:
Is TLS support and/or a workaround for those crashes something that's on
the radar?
That release had a few issues with generating 64-bit TLS code. Those
issues have been fixed but I haven't uploaded a new binary. The new
compiler can pass most of th
On 1/16/2012 3:34 PM, Manu wrote:
I went through that stuff you submitted the patch for, then I also ran
into a conflict between linux sockets and windows sockets, and that's as
far as I got when I stopped.
The only posix file that gave me trouble was `core/sys/posix/sys/un.d`.
GDC turns it i
On 1/16/2012 1:42 PM, Iain Buclaw wrote:
Cool. Do you have anything in your MinGW patch queue that might be
worth merging in?
Maybe. I'm merging some of the trivial changes now.
In addition there is TLS support but that requires patches to the
runtime, bintutils and GCC. Support for C99 st
On 1/16/2012 4:03 AM, Manu wrote:
I had creeping problems building phobos (MinGW) last night stemming from
D_InlineAsm being removed. Didn't manage to get it working in the end,
gave up and went to bed :)
https://bitbucket.org/goshawk/gdc/changeset/dc87c7212d70
Some of the stack functions need
64-bit is ready.
64-Bit Binary
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-9841510e8ba6-20120109.7z
Running the testsuite had additional failures.
# MinGW64 -m32 failures
DISABLED_TESTS += test34 variadic
# MinGW64 -m64 failures
# ICE
DISABLED_TESTS += dhry
DISABLED_TE
On 1/9/2012 4:35 PM, Manu wrote:
Awww damn it! I was all excited, thought you'd saved me the pain...
until I realised this isn't the latest version :(
GDC is under active development. It may no longer be the tip, but it's
only a few revisions from it.
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Posted updated binaries for MinGW32 and MinGW64.
* Requires TDM GCC 4.6.1 32 or 64-bit edition.
* GDC revision 9841510e8ba6.
* Contains modified binutils and runtime files for TLS.
* 7-zip format: http://7-zi
Please post all issues in D.gnu or on GDC's site
https://bitbucket.org/goshawk/gdc
Posted updated binaries for MinGW32 and MinGW64.
* Requires TDM GCC 4.6.1 32 or 64-bit edition.
* GDC revision e7639c523add.
* Contains modified binutils and runtime files for TLS.
* 7-zip format: http://7-zi
On 12/19/2011 12:07 PM, dsimcha wrote:
...And with D1, everything works again in 32-bit mode but in 64-bit mode:
gdc -o hello.exe hello.d -m64
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib/libgphobos.a(
win32.o):(.text+0xc3): undefined reference to `_data_start__'
c:/ming
On 12/19/2011 12:04 AM, dsimcha wrote:
Nice work. One question, though: Why are you using an ancient revision
of GDC? I'll try your build out, but I'm not sure most of my code still
compiles on 2.055. That's **two** releases behind now, and two very
significant releases.
GDC support for 2.056 a
Please post all issues in D.gnu or on GDC's bitbucket site
https://bitbucket.org/goshawk/gdc
* Built against TDM64 GCC 4.6.1: http://tdm-gcc.tdragon.net/
* Built against GDC revision 7e22befef29c.
* Working TLS support.
* Updated binutils and mingw runtime for TLS support.
* new gas dire
Sorry, it's really a packaging issue. Switching GDC to target i686
changed some library and executable paths resulting in these issues.
I've repackaged and tested it from a clean install.
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm-1-gdc-7e22befef29c-20111211.7z
On 12/10/2011 12:27 PM, Andrej Mitrovic wrote:
Doesn't work with TDM 4.6.1 bundle installer.
>
The only place I've found gmp is here:
http://sourceforge.net/projects/mingw/files/MinGW/Base/gmp/gmp-5.0.1-1/
And that one is libgmp-10.dll, not libgmp-3.dll.
Did you install TDM-GCC or MinGW Stabl
Updated binaries.
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm-1-gdc-7e22befef29c-20111210.7z
* GDC now targets i686 processors. Was targeting i386 which required
substituting functions for atomic instructions.
I will release MinGW64 binaries soon then work on updating to tip an
On 12/5/2011 8:28 PM, Trass3r wrote:
Why is D1 still the default?
Because this is the first release where I felt D2 was capable of being
the default and I forgot about it until writing the post. It also
requires some reworking of the changes that enable dual compilers.
but why is there a zi
Please post all issues in D.gnu or on GDC's bitbucket site
https://bitbucket.org/goshawk/gdc
* Built against TDM GCC 4.6.1: http://tdm-gcc.tdragon.net/
* Built against GDC revision 7e22befef29c.
* Working TLS support.
* Updated binutils and mingw runtime for TLS support.
* new gas direct
On 7/27/2011 12:36 AM, dune wrote:
BTW: ascii.d is missing from the include directory and the ascii functions are
missing as well.
DMD 2.052 does not have an ascii.d, it was added later.
On 7/25/2011 11:58 AM, Trass3r wrote:
* default branch. DMD 1.067/2.052
* Contains both D1(default/-v1) and D2(-v2).
Thx for your work!
Btw the default branch already contains 2.054.
The binaries are still 2.052. Iain just merged the 4.6 branch
yesterday, which contained 2.054. I wanted to
On 7/25/2011 11:45 AM, Daniel Green wrote:
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.1-tdm64-1-gdc-r575-20110725.zip
I mislabeled the file. It is really GCC 4.5.2, here is an updated link
to avoid confusion.
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.2-tdm64-1-gdc-r575
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.1-tdm64-1-gdc-r575-20110725.zip
* Compatible with TDM's 64-bit compiler suite.
* Binaries are 32-bit.
* Can generate 32-bit and 64-bit object files.
* default branch. DMD 1.067/2.052
* Contains both D1(default/-v1) and D2(-v2).
See https:
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.2-tdm-1-gdc-r575-20110717.zip
* Still based off TDM GCC 4.5.2.
* 32-bit only.
* May have issues with Dlls. D2 only.
* default branch. DMD 1.067/2.052
* Contains both D1(default/-v1) and D2(-v2).
See https://bitbucket.org/venix1/mingw-gdc
On 5/29/2011 4:20 AM, Vladimir Panteleev wrote:
Pretty sure it's not the calling convention. aApplycdzd exists only in
the object files for modules which use foreach (dchar c; someString).
I looked into the issue and the problem lines with the use of sprintf in
the compiler source. Line 1833
On 5/28/2011 1:53 AM, Vladimir Panteleev wrote:
On Sat, 28 May 2011 06:32:02 +0300, Daniel Green wrote:
You have to change os_query_staticdataseg in win32.d it's done in the
patch.
Thanks, didn't expect that part to be that simple.
The next obstacle seems to be _aApplycdzd/_
On 5/27/2011 4:55 PM, Vladimir Panteleev wrote:
Where is the patch? In the original post you said you'd post the patches
"tomorrow", but I haven't seen them here or linked from the building
instructions.
Forgot to mention it but all patches relating to Win64 support can be
found here.
https:
On 5/25/2011 6:59 PM, Vladimir Panteleev wrote:
However, it doesn't look like the Phobos in HG tip is ready for 64-bit.
There were some trivial problems in std.stream, but lots of
warnings/errors in the GC.
Is that with the patch? The errors should be uint to size_t
conversions. However, I r
On 5/14/2011 11:02 PM, dsimcha wrote:
Now that you have the patches "officially" submitted, are you going to
post binaries?
I'll get binaries posted when I have a build script that can go from
start to finish without human intervention.
On 4/30/2011 3:20 PM, dsimcha wrote:
Nice! Based on your other post, I'm a little confused. Is this a
barebones 64-bit compiler, or is it at least an attempt to patch Phobos
and druntime to work on Win64?
I've attempted to patch Phobos and got it to compile. I think there are
issues resulting
On 4/27/2011 12:03 AM, Brad Roberts wrote:
You should file bug reports with the appropriate patches.
The patches are diffed from GDC sources, is it recommended to apply them
to the phobos/druntime trunk or leave them as is. I can't test them
against DMD. I do not know how GDC and DMD phobos
https://bitbucket.org/goshawk/gdc/wiki/MinGW64
The above link details the process of building GDC with TDM64. The
instructions are not great at the moment. It's getting late and I
rushed them. I'll get the patches posted sometime tomorrow.
Post any questions or comments in this newsgroup a
MinGW-w64 D1 with phobos has been successfully compiled. Phobos
contained 3 errors. Two were Windows function calls. Phobos uses
size_t but Win64 uses uint. The other was with the GC relating to
Windows stack information. Several functions in the GC expect uint
which causes warnings and sh
Thought I'd post an update. I spent last weekend building the support
libraries for MinGW-w64. I also took the opportunity to automate the
build process from start to finish.
I had to do this inside VirtualBox which not only adds significantly to
compiling, the latest version(4.0.4) kept loc
On 4/18/2011 5:15 AM, Kagamin wrote:
Such feature would be fantastic.
I don't see this becoming a feature of D for quite some time if ever
although it would make the enforcement easier.
Once the subsets are defined the next challenge is enforcing them. Two
ideas come to me right now. Enforcin
On 4/16/2011 9:21 PM, Brendan Simon (eTRIX) wrote:
I believe that eCos is written in C++ (or a restricted subset), and I
presume that it performs quite well, so given that, I see no reason why
a D based OS/RTOS could not perform as well as eCos or other OSes.
Squeak is a good example of that too
rd work.) I've also noticed that GDC has been ported to Windows using
MinGW (thanks to Daniel Green), but as far as I can tell it only supports 32.
Are there any major, fundamental roadblocks to 64 support or are we a few bug
fixes away?
That was something I was going to look into this
On 4/9/2011 5:58 AM, Gour-Gadadhara Dasa wrote:
Seeing that we probably won't have 64bit DMD, I wonder whether gdc2
is the best bet for 64bit D2 development on Free(PC)BSD?
Iain put in some work over the weekend getting 64bit GDC working with
linux. If your willing to put in the effort to get *
GDC built against TDM-GCC 4.5.2. Nothing new.
- Install TDM-GCC 4.5.2 32-bit SjLj.
- Extract GDC zip into installation folder.
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.2-tdm-1-gdc-r510-20110407.zip
http://tdm-gcc.tdragon.net/download
I was doing some searching today and came across an old post of mine.
http://www.digitalmars.com/d/archives/D/gnu/1599.html
I imagine the patch is outdated and unnecessary. However the phobos to
dll conversion may be of interest to some. Don't expect it to work
without some effort though and
On 3/29/2011 5:49 PM, Andrej Mitrovic wrote:
On 3/29/11, Daniel Green wrote:
In the meantime, anybody can still
download the installer for 4.5.1 on the TDM website. That should
include all dependencies.
The problem with that installer is that it checks for updated versions
on the web
SJLJ is the only version supported.
@Andrej
I'll work on updating to 4.5.2. In the meantime, anybody can still
download the installer for 4.5.1 on the TDM website. That should
include all dependencies.
http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/
@A
On 3/28/2011 10:47 PM, dsimcha wrote:
Do/will these releases support 64 bits?
As soon as any general issues with MinGW are worked out. I would like
to begin work with 64 bits. I specifically chose TDM as a base because
they have a 64 bit release process already.
If not, is the problem tech
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.1-tdm-1-gdc-r510-20110328.zip
New/Changed Features:
* GDC was updated to r510
* std.stdio should now work properly for D2.
Unchanged/Pending:
* libgphobos is still not stripped. An attempt was made to separate
debug information but resulte
Michael P. Wrote:
> After that, I hope to merge in a new D front end, 1.047.
There is some sort of internal change to will require updating of the glue
code. I don't know what it is, but it causes the 1.047 front end to crash.
-Dan
I forgot to mention the extra files needed to finish installation,
because I really wouldn't recommend copying the files from your MinGW
install.
Copied from http://www.tdragon.net/recentgcc/
All files can be found at http://sourceforge.net/projects/mingw/files/
* binutils : binutils-2.19.1-m
First I want to mention, this is not a usable version of GDC. There is
a link issue with the phobos library and if you go through the effort of
compiling tango-0.99.8, you're bound to run into a couple other issues.
On the other hand, I don't know of anyone who is actively working with
GDC an
Recently I tried compiling goshawk's gdc,1.045 at the moment, for
Windows using TDM's GCC/mingw32 patches and build files. When I started
I chose Cygwin as an environment because the MinGW website was down at
the time. The compiler has been successfully built and the process to
build it somew
90 matches
Mail list logo
