,
i.A. Kai Tietz
PS: You can find the patch in the thread "Re: PE+ and new COFF format for
x86_64 target for XP64 and Vista binaries"
(I tested it with cygwin and linux environment)
--------
Kai Tietz - Software engineering
OneVision Software Entwick
27;t work this way ...
Chears,
i.A. Kai Tietz
"David Lariviere" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
20.09.2006 09:16
To
cc
Subject
Linking Assembly Code - Can't resolve printf
I have a simple assembly program that I am trying to compile, but ld
cannot
n your shell.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwi
ingw32 on sf.net in project mingw-w64. It is currently an alpha
version. FX compiler its mingw cross compiler version using this crt.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bun
Hi,
cygwin64 shares for 64-bit the ABI of Windows native. This is caused
by different reasons (eg. unwind-table description for prologue, etc).
So for Windows targets va_list is indeed of 'char *' type. And this
is ok. The variant of x86_64 abi, which uses indeed a
structure-variant for variadi
Hmm, I think that stuff around EXCEPTION_DEBUG_EVENT is that what you
are searching for. See for some details
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679299%28v=vs.85%29.aspx
Regards,
Kai
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cy
;>>
>> >>>I briefly tested this other patch with my test case from the mail above,
>> >>>and
>> >>>it doesn't seem to help.
>> >>>[...]
>> >>I asked DJ to take another look, but I guess ultimately we need the
>>
cygwin-ow...@cygwin.com wrote on 05.02.2009 13:53:42:
>
> Hi There,
>
> please go through the follows:
>
> 1) I want to create a 64 bit DLL using Cygwin in Windows Serever
2003
> 64 bit platform.
> 2) I am using Cygwin to run the make file
> 3) In the make file I have a macro ?C
Hello Eric,
> Here's the very simple Makefile that was used:
> CXX = g++
> CXXFLAGS = -Wall -Wextra -std=c++98 -pedantic -Werror -c
> LDFLAGS = -s -o $(EXEC)
Add to your LDFLAGS --enable-auto-import
That should remove those warnings for you.
Cheers,
Kai
Regards
e for Cygwin and MinGW targets. It
> +specifies that a Unicode application is to be generated by
> +instructing the linker to set the PE header subsystem type
> +appropriately.
> @end table
>
> See also under @ref{i386 and x86-64 Options} for standard options.
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
This feature would be nice for mingw.org and cygwin, but it is already
present on gcc. To reinvent the wheel makes less sense here IMHO. The
mingw-w64 supports -municode for gcc 4.5 for the triplet -w64-mingw*
at the moment, as cygwin/mingw don't have unicode startup facility at the
moment.
And btw the patch here (especially the parts related to gcc) is here on
the wrong list. And also I would prefer for the gcc patch, that it uses
current implementation and names, instead of choosing here some new one.
Regards,
Kai Tietz
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
2012/2/7 Corinna Vinschen wrote:
> On Feb 7 14:10, carolus wrote:
>> On 2/7/2012 1:51 PM, Tim Prince wrote:
>> >On 2/6/2012 2:29 PM, Charles D. Russell wrote:
>> >
>> >>i686-w64-mingw32-gfortran.exe hello.f -o hello
>> >>
>> >>cdr@dell03 ~/mingtest
>> >>$ ./hello
>> >>/home/cdr/mingtest/hello.exe:
Hello,
with recent cygwin version (cygwin1.dll 1.7.7 (1007.7.0.0)) I get
while building gcc the following error message:
"/home/ktietz/source/rth/gcc/buildw64/./gcc/as: fork: Resource
temporarily unavaiable".
This behavior is new as with older version I didn't saw this problem.
Is this an already
Hello,
I just want to report pretty annoying issues on Win7 64-bit and
cygwin. The interesting part is that by version 1.7.5 those issues
aren't occuring.
I use cygwin for testing via cross-compiler gcc and therefore let run
DejaGnu testsuite for it. This works in general fine, but randomly and
ra
2010/12/22 :
> On Wed, 22 Dec 2010 14:13:15 +0100, Frédéric Bron
> wrote:
>
> I checked the Make file, it used this flag:
> gcc -mno-cygwin -g -Wl,--add-stdcall-alias -Wl,--export-all-symbols ...
replace gcc by gcc-3
gcc 4 is now the default on cygwin but the cross compiler
2010/12/22 :
> On Wed, 22 Dec 2010 15:11:18 +0100, Kai Tietz
> wrote:
>
>> 2010/12/22 :
>>>
>>> On Wed, 22 Dec 2010 14:13:15 +0100, Frédéric Bron
>>> wrote:
>>>
>>>>>>> I checked the Make file, it used this flag:
>
2010/12/22 :
> On Wed, 22 Dec 2010 15:36:01 +0100, Kai Tietz
> wrote:
>
>> 2010/12/22 :
>>>
>>> On Wed, 22 Dec 2010 15:11:18 +0100, Kai Tietz
>>> wrote:
>>>
>>>> 2010/12/22 :
>>>>>
>>>>> On Wed, 22
Yes, good progress. A lot of those x64 Win7 issues don't appear
anymore for me and I didn't had now for some time no more forking
issues.
Thanks,
Kai
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/do
2011/4/12 Hans Horn :
> Folks,
>
> has anybody got any experience interfacing (g)fortran routines with Java via
> JNI?
>
> I'm on 64bit Windows7 using cygwin
> x86_64-w64-mingw32-gcc and x86_64-w64-mingw32-gfortran, both v4.5.2
>
> Java: jdk-6u24-windows-x64
>
> Even though I can statically link th
2011/8/20 JonY :
> On 8/20/2011 02:39, Sam Steingold wrote:
>>> * Corinna Vinschen [2011-08-19 14:00:44 +0200]:
>>>
>>> On Aug 19 18:19, JonY wrote:
On 8/19/2011 07:37, Sam Steingold wrote:
>> * JonY [2011-08-19 06:39:03 +0800]:
>>
>> You are supposed to use -I to add the ddk pat
Hi,
the issue you are noticing here is that pdata information differs
between different archtiectures. The first you have shown here is the
definition of the spark,mips, and (IIRC) arm architecture. The second
one you've shown is the definition of pdata for x64 architecture. For
x86 itself ther
2012/10/20 JonY wrote:
> On 10/20/2012 21:12, Christian Franke wrote:
>> Just for Info:
>>
>> The new /usr/include/w32api/windef.h does no longer define _WIN32.
>>
>> This may require compile fixes for some sources which check only for
>> _WIN32 and not for __CYGWIN__ after windows.h is included.
>
2012/11/21 Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi,
>
> Could somebody please explain to me why windres complains about
> native windows dlls (let alone I can't get it work with new ones built
> on Cygwin). For example:
>
> windres /cygdrive/c/windows/system32/ntdll.dll
> windres: unexpec
2012/11/26 Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> There is an issue about parsing version-resource in binary-format in
>> binutils.
>
> Perhaps there is more: an .rc file with version info compiled by the
> current windres does not populate almost any fields on the "Details"
> tab of the f
2013/1/25 marco atzeri :
> On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
>
>> I already explained why: The SEGV happens during relocation.
>> The file header has been changed already. If you call the
>> same rebase, it will try to rebase the file to the same new
>> address. If current file base
Well, here are my 2-cents about that issue. In general it is a flaw
to have an base-relocation in debug-section, as this means such debug
information can't be moved into a separate debug-file anymore. A
debug-file has no relocation-information.
Nevertheless it would be good, if objcopy gets adjus
2013/4/9 Corinna Vinschen schrieb:
> On Apr 9 01:05, Charles Wilson wrote:
>> The following are missing from the definition of enum
>> WELL_KNOWN_SID_TYPE in winnt.h:
>> [...]
>> Should I send this as a patch to mingw64.sf (are they the
>> maintainers of our w32api now?)
>
> Yes, and yes.
>
>
> Th
2013/5/3 Jan Nijtmans wrote:
> 2013/5/3 Christopher Faylor:
>> We make ABSOLUTELY no guarantees that our errnos will match any other
>> system's. You can't expect that you will be able to use Cygwin errno's
>> in pure Windows applications. We really don't care if our errnos match
>> those of Wind
2013/7/4 Alexey Pavlov wrote:
> 2013/7/4 Corinna Vinschen:
>> On Jul 4 12:37, Alexey Pavlov wrote:
>>> 2013/7/4 Corinna Vinschen:
>>> > On Jul 4 13:09, Alexey Pavlov wrote:
>>> >> 2013-06-18 Alexey Pavlov
>>> >>
>>> >> * mount.cc: Allow using a shortened version of mount points in /etc/fstab
>>>
2013/9/10 JonY <10wa...@gmail.com>:
> Hi,
>
> Seems like there is a duplicate definition of TRANSACTION_ALL_ACCESS and
> THREAD_INFORMATION_CLASS, found by one of the msys2 developers.
>
> See attached log.
I can't see on trunk that those symbols are double defined by
mingw-w64. So there might be
2013/9/10 JonY <10wa...@gmail.com>:
> Hi,
>
> Seems like there is a duplicate definition of TRANSACTION_ALL_ACCESS and
> THREAD_INFORMATION_CLASS, found by one of the msys2 developers.
>
> See attached log.
I can't see on trunk that those symbols are double defined by
mingw-w64. So there might be
013/9/10 JonY
>>
>> On 9/10/2013 16:44, Kai Tietz wrote:
>> > 2013/9/10 JonY:
>> >> Hi,
>> >>
>> >> Seems like there is a duplicate definition of TRANSACTION_ALL_ACCESS and
>> >> THREAD_INFORMATION_CLASS, found by one of the msys2 d
Hey,
Just my 5 cents to this. As Corinna pointed out, is the case, that a
"small" memory model application works for you, no valid prove that
all application will work on such a model. Another thing, which
cygwin depends heavily on is the pseudo-relocation stuff. It is not
guaranteed that code
32 matches
Mail list logo
