Gerrit P. Haase wrote:
Hi all,
I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release,
I'm in contact with the maintainer David Friedman, he successfully
compiled the current (0.12.1) sources with MinGW and I expect that he
also has tested it with other supported platforms,
Gerrit P. Haase wrote:
Gerrit P. Haase wrote:
Hi all,
I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release,
I'm in contact with the maintainer David Friedman, he successfully
compiled the current (0.12.1) sources with MinGW and I expect that he
also has tested it with
Gerrit P. Haase wrote:
Maybe this is the problem here:
!!defined (TARGET_IS_PE_COFF)
Is TARGET_IS_PE_COFF defined for Cygwin?
Yes it is:
#define TARGET_IS_PE_COFF 1
Is this wrong in the d-codegen source? I'kll try what changes if I
include Cygwin:
! #if defined (ASM_OUTPUT_DEF) \
Gerrit P. Haase wrote:
Hi all,
I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release,
I'm in contact with the maintainer David Friedman, he successfully
compiled the current (0.12.1) sources with MinGW and I expect that he
also has tested it with other supported platforms,
Am Dienstag, 7. Juni 2005 17:25 schrieb Gerrit P. Haase:
Gerrit P. Haase wrote:
[...]
Sadly, neither can I help you nor am I able to provide something at least
remotely useful. But I can provide something utterly useless (this mail) so
you are not completely alone in this thread...
Regards
David Friedman wrote:
Maybe this is the problem here:
!!defined (TARGET_IS_PE_COFF)
Is TARGET_IS_PE_COFF defined for Cygwin?
Yes it is:
#define TARGET_IS_PE_COFF 1
Is this wrong in the d-codegen source? I'kll try what changes if I
include Cygwin:
! #if defined (ASM_OUTPUT_DEF) \
!
Original Message
From: Gerrit P. Haase
Sent: 07 June 2005 11:59
Hi all,
I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release,
What is new in the source regarding this problem is this patch which
gives me the error cited below:
diff -cr d-0.12/d-codegen.cc
David Friedman wrote:
This is probably a better test:
--- d-codegen.cc.origTue Jun 7 14:10:57 2005
+++ d-codegen.ccTue Jun 7 14:11:55 2005
@@ -1757,7 +1757,7 @@
char buf[256];
#if defined (TARGET_IS_PE_COFF)
- if (DECL_ONE_ONLY (function))
+ // if (DECL_ONE_ONLY (function))
-Original Message-
From: Krzysztof Duleba
Sent: Thursday, February 19, 2004 4:11 PM
Subject: Re: Assembler
Krzysztof Duleba wrote:
Googling brought me to http://line.sourceforge.net,
which may be more along the lines of what you seek.
I tried it out, with no success. Binary version
Krzysztof Duleba wrote:
I gave up. I see no chance to compile Line at all. And even
if I succeed, Line will probably bail out.
Yes, I noticed that LINE was a dead project after you
mentioned that you were trying to recompile it. I was
hoping you would have success, since it sounded like
a
Williams, Gerald S (Jerry) wrote:
I wanted to try out my app with some deassembler, but
I haven't found anything interesting. Which one do you
use (in Linux)?
I don't do much X86 disassembling (most of my assembly
coding is in ARM or DSP), but I would start with ndisasm
(the nasm
Williams, Gerald S (Jerry) wrote:
Googling brought me to http://line.sourceforge.net,
which may be more along the lines of what you seek.
Seems to be a Dead Project(TM). No updates or releases since May 29, 2001.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Krzysztof Duleba wrote:
Googling brought me to http://line.sourceforge.net,
which may be more along the lines of what you seek.
I tried it out, with no success. Binary version fails to run it's own
hello
and rawhello programs and source produces so many serious errors during
the
Krzysztof Duleba wrote:
Why not? c code, translated to asm with -c -S on linux box,
can be later compiled and linked with Cygwin's gcc and works
fine. As you see, I have a good reason to believe that nasm's
int 0x80 will work too. So maybe I should simply look for a
nasm - gcc's assembler
Igor Pechtchanski wrote:
Most of the C code on Linux doesn't use int 0x80. It normally invokes
user-level functions that invoke system calls.
Why not go the same route
with Cygwin? In one of the previous messages in this thread, there was an
example of calling printf from assembly. You
Williams, Gerald S (Jerry) wrote:
int 0x80 is part of Linux, not nasm.
Of course.
In fact, nasm was
generating the int 0x80 instructions just fine--they
simply don't work under Windows. So such a translator
wouldn't help.
A translator that changes int 0x80 to function calls? It doesn't
At 09:04 AM 2/18/2004, Krzysztof Duleba you wrote:
Williams, Gerald S (Jerry) wrote:
By asking for int 0x80 support, you're really asking
for the ability to run precompiled Linux applications.
What do you mean by precompiled?
He means Linux ix86 binaries running unmodified on Windows.
That
Williams, Gerald S (Jerry) wrote:
Googling brought me to http://line.sourceforge.net,
which may be more along the lines of what you seek.
I tried it out, with no success. Binary version fails to run it's own hello
and rawhello programs and source produces so many serious errors during the
Krzysztof Duleba wrote:
A translator that changes int 0x80 to function calls? It doesn't seem too
difficult, but I probably miss something.
So write a perl script. The list of syscalls is defined in the Linux
kernel in unistd.h:
Brian Dessent wrote:
A translator that changes int 0x80 to function calls? It doesn't seem too
difficult, but I probably miss something.
So write a perl script.
The list of syscalls is defined in the Linux
kernel in unistd.h:
Krzysztof Duleba wrote:
I wanted to test some of my linux assembler code on my
Windows-Cygwin box.
Is it possible at all?
I don't know about using BIOS calls, etc., but I've
assembled and linked a few NASM assembly functions.
I didn't use ELF format, though. There's a gnuwin32
format that
Williams, Gerald S (Jerry) wrote:
I wanted to test some of my linux assembler code on my
Windows-Cygwin box.
Is it possible at all?
I don't know about using BIOS calls, etc., but I've
assembled and linked a few NASM assembly functions.
What about Linux syscalls? Will Cygwin emulation layer
Krzysztof Duleba wrote:
What about Linux syscalls? Will Cygwin emulation layer match
it?
I just Googled int 0x80. So THAT'S what you're
trying to do. :-)
No, I think your experiment shows that Cygwin is
not emulating Linux syscalls at that level. Nor
would I have expected it to.
On the other
Williams, Gerald S (Jerry) wrote:
What about Linux syscalls? Will Cygwin emulation layer match
it?
I just Googled int 0x80. So THAT'S what you're
trying to do. :-)
:-)
No, I think your experiment shows that Cygwin is
not emulating Linux syscalls at that level.
Really?
Nor would I have
On Tue, 17 Feb 2004, Krzysztof Duleba wrote:
Williams, Gerald S (Jerry) wrote:
What about Linux syscalls? Will Cygwin emulation layer match
it?
I just Googled int 0x80. So THAT'S what you're
trying to do. :-)
:-)
No, I think your experiment shows that Cygwin is
not emulating
Hi,
Replies inline below.
On Mon, 28 Jul 2003, Guy wrote:
G'day all,
I've recently installed cygwin v1.5.0-1 and gcc v3.2.3 on my machine
FYI, cygwin 1.5.0 is a test release... It should still work, but you
might also try it with 1.3.22 and let this list know if there's a
regression in
Igor Pechtchanski wrote:
Hi,
Replies inline below.
On Mon, 28 Jul 2003, Guy wrote:
G'day all,
I've recently installed cygwin v1.5.0-1 and gcc v3.2.3 on my machine
FYI, cygwin 1.5.0 is a test release... It should still work, but you
might also try it with 1.3.22 and let this list know if
On Sun, Jul 27, 2003 at 10:26:47PM -0400, Larry Hall wrote:
You didn't -- Windows did. I'm not quite sure why /cygdrive/c/TEMP
as the value for TEMP doesn't work for you (works for me)... See guesses
above.
Or http://cygwin.com/problems.html.
Also verify that c:\temp actually exists.
--
Please
28 matches
Mail list logo
