IMO, anybody who uses -mrtd (with or without decorations) is asking
for
trouble.
Unless you are planning to use a gfortran dll in a VisualBasic app, I
can see little reason to change from the default "C" calling
convention.
That precise reason is, as far as I understand, important for some
Hi All,
I'm new to this and searched Google and the mailing lists
a bit before posting this. I'm not subscribed to this list,
so I'd appreciate it if whoever answered CCed me directly.
I tried building gcc trunk on Darwin / Intel:
imac20:/datal/gcc_build mohanembar$ uname -a
Darwin imac20.local
On Mar 10, 2007, at 6:43 AM, Mohan Embar wrote:
I tried building gcc trunk on Darwin / Intel:
/datal/gcc/gcc/gcc/config/i386/darwin.h:244: unterminated comment
or string; unexpected EOF
You should be able to update and build now... Let us know if not.
--
http://gcc.gnu.org/onlinedocs/gccint/Misc.html#Misc
- Macro: FUNCTION_MODE
An alias for the machine mode used for memory references to functions
being called, in call RTL expressions. On most machines this should be QImode.
> @defmac FUNCTION_MODE
> An alias for the machine mode used for memory references to functions
> being called, in @code{call} RTL expressions. On most CISC machines,
> where an instruction can begin at any byte address, this should be
> @code{QImode}; on RISC machines, where all instructions ar
Danny Smith writes:
>Unless you are planning to use a gfortran dll in a VisualBasic app, I
>can see little reason to change from the default "C" calling convention
FX Coudert writes:
>That precise reason is, as far as I understand, important for some
>people. Fortran code is used for internal rout
Ross Ridge wrote:
> Danny Smith writes:
>> Unless you are planning to use a gfortran dll in a VisualBasic app, I
>> can see little reason to change from the default "C" calling convention
>
> FX Coudert writes:
>> That precise reason is, as far as I understand, important for some
>> people. Fortran
Hi all,
I've been trying to use tweak the libgfortran build machinery to get
it generate a libgfortran.dll on windows systems, but I have no luck.
I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before
AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is
indicated
FX Coudert wrote:
> I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before
> AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is
> indicated in the autobook and other online resources. but configure
> (on a cross-compiler from i686-linux to i386-pc-mingw32) still says:
D
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Zuxy Meng
> Sent: Wednesday, 7 March 2007 12:36 a.m.
>
> I've uploaded a proposed patch for this bug
> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151&action=diff).
> Putting
> crtfastmath.o
In any case, I think efforts would be better spent helping get a
modern
libtool into the tree, since the one there now is ancient and I
wouldn't
be surprised if the mingw/cygwin-specific parts have bitrotted from
years of neglect.
There is effort to get that done, as you can see in the recen
11 matches
Mail list logo
