Re: [64bit] openldap compilation doesn't produce shared libraries
2013/6/13 Corinna Vinschen wrote: > On Jun 13 10:37, Kai Tietz wrote: >> 2013/6/13 Corinna Vinschen wrote: >> > Too bad. This is a typical problem of projects which have been ported >> > to 64 bit, but only to SYSV ABI, not to MS ABI. The problem never shows >> > up in the SYSV ABI (Linux, Solaris, etc), because arguments < 64 bit are >> > zero extended when pushed on the stack. Unfortunately, in the MS ABI, >> > parameters < 64 bit are not zero extended so the higher bits can contain >> > any random value. Here, the uncasted 0 is int, so it's pushed on the >> > stack with the higher 32 bit set to any garbage this stack address >> > contains at the time. >> > >> > Given our LP64-ness, I'm wondering if we couldn't tweak gcc to zero >> > extend arguments as well, even when otherwise using the MS ABI... >> > >> > >> > Corinna >> > >> > -- >> > Corinna Vinschen Please, send mails regarding Cygwin to >> > Cygwin Maintainer cygwin AT cygwin DOT com >> > Red Hat >> >> Hmm, well, we could do that, but it means of course in some cases a >> performance-penalty. For preventing some misunderstandings about >> MS-ABI I have to note that MS-ABI also extends argument also to >> natural-stack-boundary (means 8 byte on x64). Only difference here is >> that no sign-extending is used in general (in oppose to x86_64 ABI). >> So as quick feature this isn't implementable AFAICS due it has impact >> on behavior and performance. > > That puzzles me quite a bit. If MS-ABI *does* extend arguments, and > only the signedness is a problem, then why does (int)0 pushes something > different on the stack than (long)0? Signedness can't be the reason > here. > > The only reason I can see for that is that the argument has not been > extended at all. Yes, it takes its 64 bit slot, but only 32 bits have > been written to the stack, apparently. Am I missing something? Yes, the save-region. A variadic-function will store for MS-ABI arguments to stack from register to save-region. variadic handling is stack-based for 32-bit and for 64-bit. Kai
Re: [64bit] openldap compilation doesn't produce shared libraries
2013/6/13 Corinna Vinschen wrote: > On Jun 12 20:52, Yaakov (Cygwin/X) wrote: >> On 2013-06-10 07:46, Dr. Volker Zell wrote: >> >I think the stack trace translates to the following: >> > >> >Stack trace: >> >FrameFunctionArgs >> >ber_get_stringbvl >> >/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:414 >> >ber_scanf >> >/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:790 >> >ldap_get_attribute_ber >> >/usr/src/debug/openldap-2.4.35-1/libraries/libldap/getattr.c:132 >> >print_entry >> >/usr/src/debug/openldap-2.4.35-1/clients/tools/ldapsearch.c:1634 >> >main >> >/usr/src/debug/openldap-2.4.35-1/clients/tools/ldapsearch.c:1222 >> > >> >The offending code line >> > case BvOff: >> > res.bo = (char *) b->result + b->off; >> > ((struct berval *) (res.bo + tot_size))->bv_val = NULL; <- >> > line 414 >> > tot_size = 0; >> > break; >> >> That is where it is crashing, but after some debugging, AFAICS the >> real culprit is the call to ber_scanf() in ldap_get_attribute_ber(). >> Presumably because this is a varargs function, the compiler wasn't >> able to handle the necessary type promotion automatically (ber_len_t >> is an unsigned long); so b->off was showing here as 0x6, >> taking line 414 off to la-la land. Patch attached and pushed to >> Ports git. > > Too bad. This is a typical problem of projects which have been ported > to 64 bit, but only to SYSV ABI, not to MS ABI. The problem never shows > up in the SYSV ABI (Linux, Solaris, etc), because arguments < 64 bit are > zero extended when pushed on the stack. Unfortunately, in the MS ABI, > parameters < 64 bit are not zero extended so the higher bits can contain > any random value. Here, the uncasted 0 is int, so it's pushed on the > stack with the higher 32 bit set to any garbage this stack address > contains at the time. > > Given our LP64-ness, I'm wondering if we couldn't tweak gcc to zero > extend arguments as well, even when otherwise using the MS ABI... > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat Hmm, well, we could do that, but it means of course in some cases a performance-penalty. For preventing some misunderstandings about MS-ABI I have to note that MS-ABI also extends argument also to natural-stack-boundary (means 8 byte on x64). Only difference here is that no sign-extending is used in general (in oppose to x86_64 ABI). So as quick feature this isn't implementable AFAICS due it has impact on behavior and performance. Regards, Kai
Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
2013/4/15 Václav Zeman wrote: > None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It > still fails the same way. Shall I create a GCC Bugzilla report from > this then? Yes, then please create an new BZ for it, and mention that there that all these options had no effect. Thanks, Kai
Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
2013/4/15 Václav Zeman : > None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It > still fails the same way. Shall I create a GCC Bugzilla report from > this then? Yes, then please create an new BZ for it, and mention that there that all these options had no effect. Thanks, Kai
Re: 64bit: cygstdc++-6.dll
2013/4/14 Corinna Vinschen wrote: > On Apr 14 11:05, Kai Tietz wrote: >> 2013/4/14 Corinna Vinschen wrote: >> > On Apr 13 21:08, Dave Korn wrote: >> >> But it's not a separate contiguous list of pointers. What's happening >> >> is >> >> that there are various structures in the .rdata that contain imported >> >> pointers. They'll be scattered throughout the .rdata, along with all the >> >> other const data that /doesn't/ have pointers that have to be >> >> auto-imported. >> >> So depending on the percentages and how it happens to end up in the link >> >> order, it could be any or all of the .rdata pages that get COWed on >> >> startup. >> > >> > Why is that so? Isn't that, in theory, a problem of gcc not sorting the >> > data in a way which decouples auto-imported stuff from not-auto-imported >> > stuff? Couldn't a gcc fix allow to separate them out into their own >> > .data_auto_import section which is then folded into .data at link time, >> > leaving the .rdata stuff alone? >> > >> > Kai, how much of this is relevant for x86_64? >> >> AFAICS it isn't relevant for x64. I even doubt it is at all relevant >> for 32-bit, too. The reason I know about why gcc put relocated const >> data into the .data section (and not as it should be into the .rdata >> one) was caused by old pseudo-relocation-code. It wasn't able to >> modify page-priviledges and therefore data has to be moved into .data >> (and even worse code-section was made writable by linker). We more >> modern pseudo-reloc code I doubt that this is still necessary. > > The pseudo-relocator for Cygwin is in the Cygwin DLL itself, and it > changes the page protection as required for V1 pseudo relocs as well. > > Given what you said, that means to me we could drop the .xa ldscript, > and move the auto import stuff back into the .rdata section where it > belongs, while keeping auto-import the default. Right, I would assume so too. >> [...] >> Also the argumentation about none-autoimporting enabled links puzzles >> me, too. If no auto-import happens there is no need to do >> page-access-remappings done by gcc or ld. As nobody writes actual to >> these pages from POV of pe-loader. Cygwin might want to optimize the >> amount of pages needing remapping by sorting pseudo-GOT-entries in >> image together, but that is for sure a different story as to move >> things from rdata into data, or making code-section writable. > > IIUC the 32 bit stuff is not organized in pseudo-GOT entries, so this > might be a bit tricky to accomplish for 32 bit, unless the affected > auto-import entries are subsumed under the .rdata_runtime_pseudo_reloc > section. > > As far as the pseudo-GOT entries in the 64 bit code are concerned, > aren't they in the .rdata_runtime_pseudo_reloc section anyway? Yes, they are by default in .rdata section. > We just have to give up the .xa ldscript method. IMHO yes, I see no good reason to move them into data, as after psuedo-relocation they are const, and have to be const. >> If cygwin needs that behavior in gcc (and binutils), then do this >> please in cygwin-specific way there. It is in general a flaw to have >> this also for native windows targets enabled. > > I don't understand what you mean here. What exactly is a flaw to have > for native windows? Auto-import? No, IMHO it is a flaw to make const-data and text sections in pe-coff-image by default writable without good need. v1 and v2 pseudo-relocation are capable to handle read-only sections. > > Corinna Kai
Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
2013/4/14 Yaakov (Cygwin/X) wrote: > On 2013-04-11 03:58, Václav Zeman wrote: >> >> I have tried to compile log4cplus (C++ logging library) on Cygwin64 >> with -flto GCC option. I am getting the following failure: >> >> lto1: internal compiler error: in add_symbol_to_partition, at >> lto/lto-partition.c:284 > > > Confirmed; I suggest you continue pursuing this upstream via your PR55902. > > > Yaakov > Hmm, not sure if this is for real the same issue. Does option -r or -nostdlib solves the issue for you? I assume that the underlying issue might be related to an bb-reorder issue (-fno-reorder-blocks might solve it too). Thanks, Kai
Re: 64bit: cygstdc++-6.dll
2013/4/14 Corinna Vinschen wrote: > On Apr 13 21:08, Dave Korn wrote: >> On 13/04/2013 11:07, Corinna Vinschen wrote: >> > On Apr 12 21:31, Dave Korn wrote: >> >> >> Nope, just vague about input and output sections. Enabling auto imports >> >> selects a linker script that causes all the .rdata in the input object >> >> files >> > >> > Out of curiosity, which linker script is that? What's the difference >> > to the "normal" one? >> >> Well, since auto import became the default, it is "the normal one", but >> that >> aside, they're both built-in scripts. Compare the output from "ld >> --disable-auto-import --verbose" and "ld --verbose" to see the difference. >> Or >> you can look at the copies that ld installs into >> /usr/i686-pc-cygwin/lib/ldscripts/; the .x file is the plain one, the .xa is >> the auto-import one. > > I'm puzzled. The .xa file supposedly foldes *all* of .rdata into the > .data section. So an executable built with --auto-import should have no > .rdata section, right? And since auto-import is on by default, none of our > binaries should have an .rdata section. But they have. I notice that > the 32 bit DLLs don't have a .rdata section, though. Does that mean > auto-import only influences DLLs? > > I also notice that 64 bit binaries and DLLs both have .rdata sections. > But AFAICS, auto-import is enabled for 64 bit, too. > >> > I'm a bit puzzled in terms of the additional R/W space this amounts to. >> > When loading an executable, there is the entire IAT which has to be >> > modified by the loader, anyway. That includes all functions and data >> > imported from other DLLs. To what extent do the auto-import entries add >> > to that? If it's just another indirection, that would add 5 bytes >> > (absolute jmp) on i686, and 8 bytes (an absolute address in a pseudo-GOT >> > table) on x86_64 per auto-imported symbol. That's not a lot, probably >> > not even a 4K page per executable. How significant is that? >> >> But it's not a separate contiguous list of pointers. What's happening is >> that there are various structures in the .rdata that contain imported >> pointers. They'll be scattered throughout the .rdata, along with all the >> other const data that /doesn't/ have pointers that have to be auto-imported. >> So depending on the percentages and how it happens to end up in the link >> order, it could be any or all of the .rdata pages that get COWed on startup. > > Why is that so? Isn't that, in theory, a problem of gcc not sorting the > data in a way which decouples auto-imported stuff from not-auto-imported > stuff? Couldn't a gcc fix allow to separate them out into their own > .data_auto_import section which is then folded into .data at link time, > leaving the .rdata stuff alone? > > Kai, how much of this is relevant for x86_64? AFAICS it isn't relevant for x64. I even doubt it is at all relevant for 32-bit, too. The reason I know about why gcc put relocated const data into the .data section (and not as it should be into the .rdata one) was caused by old pseudo-relocation-code. It wasn't able to modify page-priviledges and therefore data has to be moved into .data (and even worse code-section was made writable by linker). We more modern pseudo-reloc code I doubt that this is still necessary. I am not sure where this information comes from, but by my research I can't find documentation that pe-loader wouldn't be able to do importing into tobe-remapped pages in an efficient way. I did some tests and it works flaw-less. Also by information I got from "Windows Internals" book, I see that importing and relocation is done on none-access-limitted pages, which are later-on restricted by pe-loader to their desired access specified in PE's section-table. But well, I might misunderstood here the reasoning. Also the argumentation about none-autoimporting enabled links puzzles me, too. If no auto-import happens there is no need to do page-access-remappings done by gcc or ld. As nobody writes actual to these pages from POV of pe-loader. Cygwin might want to optimize the amount of pages needing remapping by sorting pseudo-GOT-entries in image together, but that is for sure a different story as to move things from rdata into data, or making code-section writable. If cygwin needs that behavior in gcc (and binutils), then do this please in cygwin-specific way there. It is in general a flaw to have this also for native windows targets enabled. > > Corinna Kai
Re: 64bit: Possible optimizer bug in g++ 4.8.0 20130319
Hello, 2013/3/23 Corinna Vinschen schrieb: > Thanks for the testcase. I'm not a gcc expert, so I defer to Kai. > Kai, can you have a look what happens here? > > > Thanks, > Corinna yes, this is a gcc bug. it isn't sepcial to cygwin64. It happens also for x64 mingw, so please file a regression-bug in gcc's bz. I will take a closer look about its cause. For me it looks like that unwinding-information doesn't reflect difference in stack-use here, but I will need to investigate in more detail. Thanks, Kai
Re: 64bit: Possible optimizer bug in g++ 4.8.0 20130319
Hello, 2013/3/23 Corinna Vinschen : > Thanks for the testcase. I'm not a gcc expert, so I defer to Kai. > Kai, can you have a look what happens here? > > > Thanks, > Corinna yes, this is a gcc bug. it isn't sepcial to cygwin64. It happens also for x64 mingw, so please file a regression-bug in gcc's bz. I will take a closer look about its cause. For me it looks like that unwinding-information doesn't reflect difference in stack-use here, but I will need to investigate in more detail. Thanks, Kai
Re: Maintainers please weigh in on 64-bit Cygwin
2013/3/20 Dave Korn schrieb: > On a related issue, I don't see anything related to cygwin64 in upstream > GCC. How is 64-bit Cygwin currently being built? Are you using a mingw64 > compiler and controlling things like startup files and libs linked against in > the command-line? I will begin to push patches this week to gcc upstream. It is now again in stage 1, and well, I would like to let settle down new sourceware hardware a bit before posting. You can find most important required patches at ftp://cygwin.com/pub/cygwin/64bit/ folder. The mingw-w64 compiler is required at some places for building cygwin-base stuff (utils etc), but in general cygwin64-compiler is used. > (Sorry for being so behind the times. I've got an ~20k backlog of emails > between Cygwin, binutils and GCC.) > > cheers, > DaveK Regards, Kai
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen: > On Aug 14 08:46, Andy Koppe wrote: >> Yep, mintty builds fine with that, and appears to work. For some >> reason it's 9K bigger than with the current w32api though. > > I think this is because the mingw-w64 libs come with a couple more > static elements built into the libs (GUIDs and stuff). > > Kai, can you explain the difference? > > > Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen
> On Aug 14 09:29, Corinna Vinschen wrote:
>> On Aug 14 08:25, Andy Koppe wrote:
>> > On 14 August 2012 08:18, Corinna Vinschen wrote:
>> > > On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
>> > >> On 2012-08-12 01:49, JonY wrote:
>> > >> >New w32api preliminary upload, now with mingw-w64 parts.
>> > >>
>> > >> Nack. Both mintty and xorg-server FTBFS with this w32api.
>> > >
>> > > Er... what?
>> >
>> > I had to look it up: Fails To Build From Source.
>> >
>> > /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
>> > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
>> >
>> > windef.h:23: typedef unsigned __LONG32 ULONG;
>> >
>> > It doesn't like the __LONG32.
>>
>> Ok, that's fixable. Do you include windef before windows.h? If so,
>> does it work if you switch the includes?
>
> Alternatively, can you apply this patch to windef.h and try again?
>
> Index: windef.h
> ===
> --- windef.h(revision 5370)
> +++ windef.h(working copy)
> @@ -14,6 +14,8 @@
> extern "C" {
> #endif
>
> +#include <_mingw.h>
> +
> #ifndef WINVER
> #define WINVER 0x0502
> #endif
>
>
> Corinna
Fixed at rev. 5371. The include should come before the 'extern "C" {' clause.
Thanks for reporting. It might be that there are some of those issues
remaining caused by the LP64 support-changes.
Regards,
Kai
Re: Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32
2012/6/12 Yaakov (Cygwin/X) :
> On 2012-06-04 02:10, Kai Tietz wrote:
>>
>> The change in crt/wchar.h about __mingw_ovr macro looks wrong to me,
>> or at least inconsistent. As stdio.h has same macro. At least a
>> libstdc++ bootstrap test is required for this change.
>
>
> Currently I get:
>
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libmsvcrt.a(daqubs01139.o):(.text+0x0):
> multiple definition of `_swprintf'
> io_stream_file.o:/usr/i686-w64-mingw32/sys-root/mingw/include/wchar.h:547:
> first defined here
>
> How about this change instead to both headers:
>
> --- crt/wchar.h (revision 5094)
> +++ crt/wchar.h (working copy)
> @@ -450,10 +450,10 @@
> int __cdecl __mingw_vsnwprintf (wchar_t * __restrict__ , size_t, const
> wchar_t * __restrict__ , va_list);
>
> #undef __mingw_ovr
> -#ifdef __cplusplus
> -#define __mingw_ovr inline __cdecl
> -#elif defined (__GNUC__)
> +#if defined (__GNUC__)
> #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
> +#elif defined(__cplusplus)
> +#define __mingw_ovr inline __cdecl
> #else
> #define __mingw_ovr static __cdecl
> #endif
Hmm, that's looking wrong to me, too. __GNUC__ gets defined also for
c++, So issue might be more related to inline being not inlined.
Could you provide me a small sample to reproduce this issue?
>> The hunk in winnt.h:
>> @@ -88,7 +88,7 @@ extern "C" {
>>
>> #include
>>
>> -#if defined(_X86_) || defined(__ia64__) || defined(__x86_64)
>> +#if defined(__W32API_USE_DLLIMPORT__)&& (defined(_X86_) ||
>> defined(__ia64__) || defined(__x86_64))
>> #define DECLSPEC_IMPORT __declspec(dllimport)
>> #else
>> #define DECLSPEC_IMPORT
>>
>> I would like to see here a different macro-name and the logic needs to
>> be inverted. Our default scenario uses dllimport and just in cygwin's
>> setup-case we don't want it.
>> So I would like to see here instead: !defined (__NO_USE_DLLIMPORT)
>
>
> How about just !defined(DECLSPEC_IMPORT)?
Yes, that's fine.
>
> Yaakov
> Cygwin/X
--
Kai
Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32
Yaakov, ping. Not sure if you still have interest to get your patch into our repository. The part about hiding dllimport needs a change in your patch. Also your changes about MIDL part (see Jacek's comment for this) need adjustment. I am still waiting for a revised version or it. As soon as this patch will be approved and applied to our repository, it will get into Fedora, too. Regards, Kai
Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32
2012/6/4 Corinna Vinschen:
> On Jun 4 09:10, Kai Tietz wrote:
>> Hello,
>>
>> here is my review about Yaakov's patch.
>>
>> The change in crt/wchar.h about __mingw_ovr macro looks wrong to me,
>> or at least inconsistent. As stdio.h has same macro. At least a
>> libstdc++ bootstrap test is required for this change.
>>
>> The hunks about guiddef.h are ok.
>> The hunk about ntdef.h is ok. Also the changes for propkeydef.h header, too.
>>
>> The hunk in winnt.h:
>> @@ -88,7 +88,7 @@ extern "C" {
>>
>> #include
>>
>> -#if defined(_X86_) || defined(__ia64__) || defined(__x86_64)
>> +#if defined(__W32API_USE_DLLIMPORT__) && (defined(_X86_) ||
>> defined(__ia64__) || defined(__x86_64))
>> #define DECLSPEC_IMPORT __declspec(dllimport)
>> #else
>> #define DECLSPEC_IMPORT
>>
>> I would like to see here a different macro-name and the logic needs to
>> be inverted. Our default scenario uses dllimport and just in cygwin's
>> setup-case we don't want it.
>> So I would like to see here instead: !defined (__NO_USE_DLLIMPORT)
>>
>> Rest of the hunks for winnt.h are ok.
>>
>> The hunks about winternl.header are ok, beside one nit. The change in
>> FILE_RENAME_INFORMATION about RootDir from HANDLE to ULONG type I am
>
> Did I miss something? I only see a name change:
>
> - BOOLEAN Replace;
> - HANDLE RootDir;
> + BOOLEAN ReplaceIfExists;
> + HANDLE RootDirectory;
>
> The latter names are the ones from MSDN:
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff540344%28v=vs.85%29.aspx
>
>
> Corinna
Ups, I mis-read that. Yes, indeed. change about winternl.h header are ok.
Sorry,
Kai
Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32
Hello,
here is my review about Yaakov's patch.
The change in crt/wchar.h about __mingw_ovr macro looks wrong to me,
or at least inconsistent. As stdio.h has same macro. At least a
libstdc++ bootstrap test is required for this change.
The hunks about guiddef.h are ok.
The hunk about ntdef.h is ok. Also the changes for propkeydef.h header, too.
The hunk in winnt.h:
@@ -88,7 +88,7 @@ extern "C" {
#include
-#if defined(_X86_) || defined(__ia64__) || defined(__x86_64)
+#if defined(__W32API_USE_DLLIMPORT__) && (defined(_X86_) ||
defined(__ia64__) || defined(__x86_64))
#define DECLSPEC_IMPORT __declspec(dllimport)
#else
#define DECLSPEC_IMPORT
I would like to see here a different macro-name and the logic needs to
be inverted. Our default scenario uses dllimport and just in cygwin's
setup-case we don't want it.
So I would like to see here instead: !defined (__NO_USE_DLLIMPORT)
Rest of the hunks for winnt.h are ok.
The hunks about winternl.header are ok, beside one nit. The change in
FILE_RENAME_INFORMATION about RootDir from HANDLE to ULONG type I am
not sure. If it should be a integer-scalar instead of a pointer, is
it sure that it is for 64-bit also just 32-bit wide? I would think we
should use here DWORD_PTR instead.
Regards,
Kai
Re: Mingw64 and Cygwin: header and libs layout
2012/3/25 Corinna Vinschen: > And why should this be done? It doesn't look as if Microsoft will ever > generate autoconf'ed, target-specific headers in different directories > and Mingw64 strives to create platform headers in as most compatible as > possible. Kai, what do you say Well, for the platform headers - and this is all we are talking about here AFAIU - it isn't to be expected that there are differences between native-windows gcc version or Cygwin-gcc version, which can't be covered by simple type-abstraction. In general the psdk in cygwin is required for linking, and in some situation also for building. And of course it is obvious that C-runtime parts of headers and lib have not to be installed in shared location. This doesn't make any sense to mix them. > And then, if we stick to the assumption that the platform headers will > be target dependent at one point, How would you like to solve that for > the Cygwin gcc? Introducing /usr/include/w64api? As dir or as symlink? Platform headers (at least that one for Windows) aren't target dependent in general. I think it would be even more a major flaw, if we would introduce such a difference. >> >> headers for w32api aren't huge in terms of disk space (5.5M), so just >> >> having >> >> duplicates in the appropriate places wouldn't be that bad. It's what >> >> happens >> >> every time you build libwhatever for both your native system and a >> >> cross-target anyway. > In that case you *have* to make a target specific headers assumption, > otherwise you have a break in the systematics. And then, again, how do > you let the gcc compiler access the target headers? By creating two > subdirs under /usr/include, w32api and w64api? Yes, these target-specific assumptions in gcc caused in the past already enough pain for none-in-souirceware-tree targets. I really would love if we could avoid such and infrastructural assumptions valid only for one target. I see no good reason to make for 32-bit/64-bit (well, we might get in near future even ARM support in platform-headers) platform environment two different directories. It just makes it more likely that headers from one getting incompatible to the other-one. Also it makes a multilib-scenario (if ever desired for Cygwin) much harder. That import-libaries (plus additional objects in imports) of platform-sdk have to be placed in different lib-folders (lib32/lib64) is as obvious as the built of the platform-libraries are requiring an native windows-compiler. The platform-headers (without the DDK and the direct-x specific extensions) are about 10 MB, nevertheless I agree that in modern times of huge HDD-capacities a double installation of them isn't that worse as it was in the past. > Corinna Regards, Kai
Re: Mingw64 and Cygwin: header and libs layout
Hi Corinna, I suggest the approach to install for cygwin the platform-headers to a shared place. I suggest that mingw-w64 adds to configure for headers and crt an option, which installs platform-headers/libraries to '/usr/shared/psdk_windows' location. Means under this path are the folders lib/lib64/include containing only the platform-parts. For the cygwin-based mingw-w64 cross-compiler we need to add here by spec (for headers in gcc and for libs in binutils or gcc). IMHO this should be a special configuration option for gcc (and binutils), which adds the required parts to spec-files. The CRT libraries and headers should stay IMHO in private places for toolchain. There is no need to put them under different locations or to have them at shared-locations AFAICS., as cygwin-toolchain won't provide this '-mno-cygwin' approach. So toolchains are regarding their CRT-headers isolated. Regards, Kai
Re: gcc4: next release
2010/7/7 Corinna Vinschen :
> On Jul 7 21:19, JonY wrote:
>> On 7/7/2010 20:58, Christopher Faylor wrote:
>> >On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote:
>> >>Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw*
>> >>sysroot idea. However, I don't like the idea in the least to keep
>> >>two different versions of w32api around. It's one target, so we should
>> >>have one set of headers only. Right? Wrong? None of that?
>> >
>> >Unfortunately, it sounds like we've stepped into the middle of a dispute
>> >between the mingw folks and the mingw64 folks. Maybe the best thing for
>> >us to do would be to decide to use only one or the other but not both.
>> >
>> >cgf
>> >
>>
>> Here are some of the technical issues.
>> [...]
>> As for mingw-w64 headers API, it does not support anything lower
>> than XP, Win2K is not supported, different from mingw.org's Win9X
>> compatibility.
>
> How do you do that? The XP functionality is a superset of the W2K
> functionality, which in turn is a superset of the NT4 functionality.
> So, in theory, headers supporting XP should support any earlier
> system(*).
To clarify this point. It is in fact possible to build NT4/Windows
2000 32-bit applications by mingw-w64 header-set and runtime, too. We
default to XP as default windows version. For windows OSes older then
XP, we don't provide active support (until now - obviously for 64-bit
OS has to be XP or newer).
>
> Corinna
>
> (*) Note that I ignore 95/98/Me deliberately since they deserve to be
> forgotten.
Agreed ;)
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: MingW-related setup.exe crash w/ DEP enabled
2010/3/17 Corinna Vinschen :
> On Mar 17 11:56, Chris Sutcliffe wrote:
>> HI Corinna,
>>
>> > ==
>> > Ultimate Packer for eXecutables
>> > Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007
>> > UPX 3.01 Markus Oberhumer, Laszlo Molnar & John Reiser Jul 31st
>> > 2007
>> >
>> > File size Ratio Format Name
>> > -- --- ---
>> > upx: rhsetup.exe: CantPackException: TLS callbacks are not supported
>> >
>> > Packed 1 file: 0 ok, 1 error.
>> > ==
>>
>> As of the latest mingw-runtime (3.18), TLS callbacks are now the
>> default (and currently there is no way to disable them). Does a more
>> current (i.e. 3.0.4) version of UPX support TLS? Failing that, you'll
>> have to revert to mingw-runtime 3.17.
>>
>> Let me know how you make out.
>
> UPX is only the second problem. The really serious problem is that
> the executable crashes under DEP.
>
>
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader cygwin AT cygwin DOT com
> Red Hat
>
Neither in .CRT, nor in .TLS is executable for sure. They are
containing function pointers (and for .TLS additional TLS data).
So by this for sure no DEP is reasoned.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
