date:20121113

Hi,78

2012/11/12 Corinna Vinschen vinsc...@redhat.com:
 Hi,

 the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION and
 adds a definition of SYSTEM_PAGEFILE_INFORMATION and
 SystemPagefileInformation.  It also changes the formatting of
 SYSTEM_INFORMATION_CLASS to make it a bit more readable.  Tested on 32
 and 64 bit.

 Ok to apply?

Ok, thanks.  Please apply.

 Btw., I could provide more detailed definitions of TEB, PEB, and
 types used within TEB or PEB.  Is there any interest?

Sure there is.  Only issue I see about it is that WINVER needs to be
interpreted here.  AFAIK does these structure change meaning of some
fields for different OSes (XP, Vista, Win7, ...).

Regards,
Kai

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

Hi,

2012/11/12 Václav Šmilauer e...@doxos.eu:
 Hi there,

 I would like to ask what the best/recommended practice for installing
 shared libraries under Windows/mingw is. Qt4 for instance installs DLLs
 to both $PREFIX/bin and $PREFIX/lib. I prefer to install to $PREFIX/lib
 and add it to $PATH (in addition to $PREFIX/bin), but I wonder if there
 is a good reason to put libs under bin.

 Thanks, Vaclav

This is a small question with much more impact as you might expect.
Old style is to put Runtime-DLL files into bin/ directory.  This had
some advantages as long as you just have one target to support, but in
general isn't the best solution IMHO.
More modern gcc installs its runtime-DLL files for
cross-compiler-scenario into target/lib (target/lib64/32) along
the the import-library.  This has the advantage that even for multiple
targets each target has its private destination for runtime-DLLs.  So
they don't collide.  Of course by this solution you need to add this
directory to your PATH-environment.

I would prefer to install 32-bit and 64-bit DLL files into same
directories as their import-libraries are.  This is by the way
additionally the same behavior as on *nix-setups.

Regards,
Kai

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

2012-11-13 Thread Václav Šmilauer


 This is a small question with much more impact as you might expect.
 Old style is to put Runtime-DLL files into bin/ directory.  This had
 some advantages as long as you just have one target to support, but in
 general isn't the best solution IMHO.
 More modern gcc installs its runtime-DLL files for
 cross-compiler-scenario into target/lib (target/lib64/32) along
 the the import-library.  This has the advantage that even for multiple
 targets each target has its private destination for runtime-DLLs.  So
 they don't collide.  Of course by this solution you need to add this
 directory to your PATH-environment.

 I would prefer to install 32-bit and 64-bit DLL files into same
 directories as their import-libraries are.  This is by the way
 additionally the same behavior as on *nix-setups.
I just noticed that autoconf (glib, glut, gio, gettext) installs DLLs to 
bin/ by default, and so does CMAKE (vtk).

If you were to support multiple targets (which is not my case), you will 
have clashes in bin/ anyways? Or is the idea to have only 
arch-independent scripts in bin/, the rest in target/bin, and add 
target/bin to $PATH depending on target?

Cheers, Vaclav

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Nov 13 09:21, Kai Tietz wrote:
 Hi,78
 
 2012/11/12 Corinna Vinschen vinsc...@redhat.com:
  Hi,
 
  the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION and
  adds a definition of SYSTEM_PAGEFILE_INFORMATION and
  SystemPagefileInformation.  It also changes the formatting of
  SYSTEM_INFORMATION_CLASS to make it a bit more readable.  Tested on 32
  and 64 bit.
 
  Ok to apply?
 
 Ok, thanks.  Please apply.

Thanks, done.

  Btw., I could provide more detailed definitions of TEB, PEB, and
  types used within TEB or PEB.  Is there any interest?
 
 Sure there is.  Only issue I see about it is that WINVER needs to be
 interpreted here.  AFAIK does these structure change meaning of some
 fields for different OSes (XP, Vista, Win7, ...).

Yes, that's right.  Hmm, might be a bit more tricky than I thought.  I
have a certain set of stuff as used in Cygwin and especially the stuff I
tested on 32 and 64 bit to get it really right for 64 bit.  Probably it
makes sense to apply only stuff which is not OS-dependent for now.


Corinna

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen vinsc...@redhat.com wrote:
On Nov 13 09:21, Kai Tietz wrote:
Hi,78

2012/11/12 Corinna Vinschen vinsc...@redhat.com:
Hi,

the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION and
adds a definition of SYSTEM_PAGEFILE_INFORMATION and
SystemPagefileInformation. It also changes the formatting of
SYSTEM_INFORMATION_CLASS to make it a bit more readable. Tested on 32
and 64 bit.

Ok to apply?

Ok, thanks. Please apply.

Thanks, done.

AFAIK, winternl.h doesn't expose SYSTEM_BASIC_INFORMATION details
for the reserved fields. Also see:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724509%28v=vs.85%29.aspx
Where did we retrieve those detail in the first place before even
correcting them? Of course there are user contributed stuff on
social.msdn.com, like:
http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/2c1f05d0-b764-475d-8e84-83c2d8a81795/
... but how wise is it to include such things in our headers?

Btw., I could provide more detailed definitions of TEB, PEB, and
types used within TEB or PEB. Is there any interest?

Sure there is. Only issue I see about it is that WINVER needs to be
interpreted here. AFAIK does these structure change meaning of some
fields for different OSes (XP, Vista, Win7, ...).

Yes, that's right. Hmm, might be a bit more tricky than I thought. I
have a certain set of stuff as used in Cygwin and especially the stuff I
tested on 32 and 64 bit to get it really right for 64 bit. Probably it
makes sense to apply only stuff which is not OS-dependent for now.

Corinna

--
O.S.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

2012-11-13 Thread JonY

On 11/13/2012 18:01, Corinna Vinschen wrote:
 On Nov 13 09:21, Kai Tietz wrote:
 Hi,78

 2012/11/12 Corinna Vinschen vinsc...@redhat.com:
 Hi,

 the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION and
 adds a definition of SYSTEM_PAGEFILE_INFORMATION and
 SystemPagefileInformation.  It also changes the formatting of
 SYSTEM_INFORMATION_CLASS to make it a bit more readable.  Tested on 32
 and 64 bit.

 Ok to apply?

 Ok, thanks.  Please apply.
 
 Thanks, done.
 
 Btw., I could provide more detailed definitions of TEB, PEB, and
 types used within TEB or PEB.  Is there any interest?

 Sure there is.  Only issue I see about it is that WINVER needs to be
 interpreted here.  AFAIK does these structure change meaning of some
 fields for different OSes (XP, Vista, Win7, ...).
 
 Yes, that's right.  Hmm, might be a bit more tricky than I thought.  I
 have a certain set of stuff as used in Cygwin and especially the stuff I
 tested on 32 and 64 bit to get it really right for 64 bit.  Probably it
 makes sense to apply only stuff which is not OS-dependent for now.

Yaakov asked me to update the mingw-w64 parts in Cygwin, please ping
when things have settled down so I can push an update.

Thanks.





signature.asc
Description: OpenPGP digital signature
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Nov 13 18:30, JonY wrote:
 On 11/13/2012 18:01, Corinna Vinschen wrote:
  On Nov 13 09:21, Kai Tietz wrote:
  Hi,78
 
  2012/11/12 Corinna Vinschen vinsc...@redhat.com:
  Hi,
 
  the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION and
  adds a definition of SYSTEM_PAGEFILE_INFORMATION and
  SystemPagefileInformation.  It also changes the formatting of
  SYSTEM_INFORMATION_CLASS to make it a bit more readable.  Tested on 32
  and 64 bit.
 
  Ok to apply?
 
  Ok, thanks.  Please apply.
  
  Thanks, done.
  
  Btw., I could provide more detailed definitions of TEB, PEB, and
  types used within TEB or PEB.  Is there any interest?
 
  Sure there is.  Only issue I see about it is that WINVER needs to be
  interpreted here.  AFAIK does these structure change meaning of some
  fields for different OSes (XP, Vista, Win7, ...).
  
  Yes, that's right.  Hmm, might be a bit more tricky than I thought.  I
  have a certain set of stuff as used in Cygwin and especially the stuff I
  tested on 32 and 64 bit to get it really right for 64 bit.  Probably it
  makes sense to apply only stuff which is not OS-dependent for now.
 
 Yaakov asked me to update the mingw-w64 parts in Cygwin, please ping
 when things have settled down so I can push an update.

You can push any time.  These changes will be extras, not required
for anything yet.

So far Cygwin has its own file with internal definitions, called
ntdll.h.  Right now I'm busily writing testcases to make sure the
definitions match 32 bit as well as 64 bit systems.

The idea is to push the stuff in this file to winternl.h so we can
ideally get rid of our own Windows type definitions.  This might or
might not be welcomed, though.


Corinna

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Tue, Nov 13, 2012 at 1:03 PM, Corinna Vinschen vinsc...@redhat.com wrote:
 On Nov 13 12:17, Ozkan Sezer wrote:
 On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen vinsc...@redhat.com 
 wrote:
  On Nov 13 09:21, Kai Tietz wrote:
  Hi,78
 
  2012/11/12 Corinna Vinschen vinsc...@redhat.com:
   Hi,
  
   the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION and
   adds a definition of SYSTEM_PAGEFILE_INFORMATION and
   SystemPagefileInformation.  It also changes the formatting of
   SYSTEM_INFORMATION_CLASS to make it a bit more readable.  Tested on 32
   and 64 bit.
  
   Ok to apply?
 
  Ok, thanks.  Please apply.
 
  Thanks, done.
 

 AFAIK, winternl.h doesn't expose SYSTEM_BASIC_INFORMATION details
 for the reserved fields.  Also see:
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms724509%28v=vs.85%29.aspx
 Where did we retrieve those detail in the first place before even
 correcting them?  Of course there are user contributed stuff on
 social.msdn.com, like:
 http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/2c1f05d0-b764-475d-8e84-83c2d8a81795/
 ... but how wise is it to include such things in our headers?

 As I wrote in my OP, I tested the stuff on 32 and 64 bit systems using
 my very own, self-written testcase.  Given that SYSTEM_BASIC_INFORMATION
 was already fully available in winternl.h,

This ...

  and given that the only
 change I made was to change the data types to match 64 bit, and given
 that I tested the result for consistency, I don't quite see your point...


... is my point: I don't have an objection againt your correction, I have
an objection against its full form being present in the first place.


 Corinna

--
O.S.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Nov 13 13:09, Ozkan Sezer wrote:
On Tue, Nov 13, 2012 at 1:03 PM, Corinna Vinschen vinsc...@redhat.com wrote:
On Nov 13 12:17, Ozkan Sezer wrote:
On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen vinsc...@redhat.com
wrote:
On Nov 13 09:21, Kai Tietz wrote:
Hi,78

2012/11/12 Corinna Vinschen vinsc...@redhat.com:
Hi,

Ok to apply?

Ok, thanks. Please apply.

Thanks, done.

As I wrote in my OP, I tested the stuff on 32 and 64 bit systems using
my very own, self-written testcase. Given that SYSTEM_BASIC_INFORMATION
was already fully available in winternl.h,

This ...

and given that the only
change I made was to change the data types to match 64 bit, and given
that I tested the result for consistency, I don't quite see your point...

... is my point: I don't have an objection againt your correction, I have
an objection against its full form being present in the first place.

So you want to keep winternl.h as close to upstream as possible, thus
removing already available (and tested) definitions? Personally I don't
think it makes a lot of sense to keep a Reserved1 field intact, just
because it's not documented. Nobody *has* to use the undocumented
fields, after all.

Anyway, that means the idea to move the (used and tested) definitions
from Cygwin to Mingw64 is moot.

Alternatively, what about having two definitions for each datatype? One
of them the default, close to the MS definition, the other one if you
define __WINTERNL_ENABLE_UNDOCUMENTED. This would also guard the
officially entirely undocumented datastructures.

Corinna

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

2012/11/13 Václav Šmilauer e...@doxos.eu:

 This is a small question with much more impact as you might expect.
 Old style is to put Runtime-DLL files into bin/ directory.  This had
 some advantages as long as you just have one target to support, but in
 general isn't the best solution IMHO.
 More modern gcc installs its runtime-DLL files for
 cross-compiler-scenario into target/lib (target/lib64/32) along
 the the import-library.  This has the advantage that even for multiple
 targets each target has its private destination for runtime-DLLs.  So
 they don't collide.  Of course by this solution you need to add this
 directory to your PATH-environment.

 I would prefer to install 32-bit and 64-bit DLL files into same
 directories as their import-libraries are.  This is by the way
 additionally the same behavior as on *nix-setups.
 I just noticed that autoconf (glib, glut, gio, gettext) installs DLLs to
 bin/ by default, and so does CMAKE (vtk).

 If you were to support multiple targets (which is not my case), you will
 have clashes in bin/ anyways? Or is the idea to have only
 arch-independent scripts in bin/, the rest in target/bin, and add
 target/bin to $PATH depending on target?

 Cheers, Vaclav

Right, the idea is to avoid those clashes.  It can be achieved by
mimic *nix behavior for shared objects.  Those are installed into
target-specific lib/ folder.  Why we don't do that by default is
simply caused by that *old* behavior to install into bin/.  I would
prefer to install DLL files  - at least toolchain base ones -
intospecific  lib/ folder as done already for cross-compilers for
mingw targets.


Regards,
Kai

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

2012/11/13 Corinna Vinschen vinsc...@redhat.com:
On Nov 13 13:09, Ozkan Sezer wrote:
On Tue, Nov 13, 2012 at 1:03 PM, Corinna Vinschen vinsc...@redhat.com
wrote:
On Nov 13 12:17, Ozkan Sezer wrote:
On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen vinsc...@redhat.com
wrote:
On Nov 13 09:21, Kai Tietz wrote:
Hi,78

2012/11/12 Corinna Vinschen vinsc...@redhat.com:
Hi,

Ok to apply?

Ok, thanks. Please apply.

Thanks, done.

As I wrote in my OP, I tested the stuff on 32 and 64 bit systems using
my very own, self-written testcase. Given that SYSTEM_BASIC_INFORMATION
was already fully available in winternl.h,

This ...

and given that the only
change I made was to change the data types to match 64 bit, and given
that I tested the result for consistency, I don't quite see your point...

... is my point: I don't have an objection againt your correction, I have
an objection against its full form being present in the first place.

Anyway, that means the idea to move the (used and tested) definitions
from Cygwin to Mingw64 is moot.

Well, I would welcome it as long as fields are proven OS-idependent or
showing real use-cases in applications using our winternl header. And
I think that cygwin as user is a vaild case, isn't it?

But I strongly agree to Ozkan that we don't want to have
NDK-definitions here. At least for now I see the burden to test all
cases as not sensible ... but well, I might be wrong

Hmm, this sounds like a nice idea. But I would think that it might be
better to have a switch which forces MS' PSDK mode and having
extensions enables by default - at least as long as normal use-case is
unaffected by it and our users might have an advantage by it.

Regards,
Kai

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

On Tue, Nov 13, 2012 at 7:04 AM, Kai Tietz wrote:
 2012/11/13 Václav Šmilauer e...@doxos.eu:

 This is a small question with much more impact as you might expect.
 Old style is to put Runtime-DLL files into bin/ directory.  This had
 some advantages as long as you just have one target to support, but in
 general isn't the best solution IMHO.
 More modern gcc installs its runtime-DLL files for
 cross-compiler-scenario into target/lib (target/lib64/32) along
 the the import-library.  This has the advantage that even for multiple
 targets each target has its private destination for runtime-DLLs.  So
 they don't collide.  Of course by this solution you need to add this
 directory to your PATH-environment.

 I would prefer to install 32-bit and 64-bit DLL files into same
 directories as their import-libraries are.  This is by the way
 additionally the same behavior as on *nix-setups.
 I just noticed that autoconf (glib, glut, gio, gettext) installs DLLs to
 bin/ by default, and so does CMAKE (vtk).

 If you were to support multiple targets (which is not my case), you will
 have clashes in bin/ anyways? Or is the idea to have only
 arch-independent scripts in bin/, the rest in target/bin, and add
 target/bin to $PATH depending on target?

 Cheers, Vaclav

 Right, the idea is to avoid those clashes.  It can be achieved by
 mimic *nix behavior for shared objects.  Those are installed into
 target-specific lib/ folder.  Why we don't do that by default is
 simply caused by that *old* behavior to install into bin/.  I would
 prefer to install DLL files  - at least toolchain base ones -
 intospecific  lib/ folder as done already for cross-compilers for
 mingw targets.

That doesn't address the side-by-side issue where we need a 32bit
executable matching the 64bit executable.  What do you propose for
32bit executable path versus the 64bit executable path?  The reason to
install the DLL into the bin/ directory is that the system will find
it even if the directory isn't in PATH.  Suppose I execute a binary
via an absolute path, one expects it to work regardless of the PATH
variable.  There are methods (such as mucking with the KnownDLL
registry entry, via a manifest, etc) that will allow you to move those
DLL elsewhere but because we are on Windows, it is best to follow the
default standard as recommended by the maker of the OS and it may be
different for differing versions of the OS.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa376414(v=vs.85).aspx

--
Earnie
-- https://sites.google.com/site/earnieboyd

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

2012/11/13 Earnie Boyd ear...@users.sourceforge.net

 On Tue, Nov 13, 2012 at 7:04 AM, Kai Tietz wrote:
  2012/11/13 Václav Šmilauer e...@doxos.eu:
 
  This is a small question with much more impact as you might expect.
  Old style is to put Runtime-DLL files into bin/ directory.  This had
  some advantages as long as you just have one target to support, but in
  general isn't the best solution IMHO.
  More modern gcc installs its runtime-DLL files for
  cross-compiler-scenario into target/lib (target/lib64/32) along
  the the import-library.  This has the advantage that even for multiple
  targets each target has its private destination for runtime-DLLs.  So
  they don't collide.  Of course by this solution you need to add this
  directory to your PATH-environment.
 
  I would prefer to install 32-bit and 64-bit DLL files into same
  directories as their import-libraries are.  This is by the way
  additionally the same behavior as on *nix-setups.
  I just noticed that autoconf (glib, glut, gio, gettext) installs DLLs to
  bin/ by default, and so does CMAKE (vtk).
 
  If you were to support multiple targets (which is not my case), you will
  have clashes in bin/ anyways? Or is the idea to have only
  arch-independent scripts in bin/, the rest in target/bin, and add
  target/bin to $PATH depending on target?
 
  Cheers, Vaclav
 
  Right, the idea is to avoid those clashes.  It can be achieved by
  mimic *nix behavior for shared objects.  Those are installed into
  target-specific lib/ folder.  Why we don't do that by default is
  simply caused by that *old* behavior to install into bin/.  I would
  prefer to install DLL files  - at least toolchain base ones -
  intospecific  lib/ folder as done already for cross-compilers for
  mingw targets.

 That doesn't address the side-by-side issue where we need a 32bit
 executable matching the 64bit executable.  What do you propose for
 32bit executable path versus the 64bit executable path?  The reason to
 install the DLL into the bin/ directory is that the system will find
 it even if the directory isn't in PATH.  Suppose I execute a binary
 via an absolute path, one expects it to work regardless of the PATH
 variable.  There are methods (such as mucking with the KnownDLL
 registry entry, via a manifest, etc) that will allow you to move those
 DLL elsewhere but because we are on Windows, it is best to follow the
 default standard as recommended by the maker of the OS and it may be
 different for differing versions of the OS.


 http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa376414(v=vs.85).aspx


Oh yes, let's impose a unnecessarily complicated, proprietary, non-portable
(across OS versions) scheme on the developers/users to account for a case
which virtually never happens (installing 32 and 64-bit executables
alongside each other)

Windows was never designed to be monolithic (wrt 32 and 64-bit)... Just
look at the system32 and sysWoW64 directory in C:\Windows. Install
differing architectures side by side, not mucked with manifests that
overcomplicate things.

To execute a binary in the scheme Kai suggests, either the relevant DLL
needs to be copied (which has to be done to install to an end-user's system
anyways) or you set the PATH on the development machine.

To be honest, this is the mess I completely avoid by having to seperate
build directories and toolchains for all my stuff, one per bitness. I know
this isn't very future-friendly, but hey, I don't want to muck with too
much muck ;-)

Ruben.


 --
 Earnie
 -- https://sites.google.com/site/earnieboyd


 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

2012/11/13 Earnie Boyd ear...@users.sourceforge.net

 On Tue, Nov 13, 2012 at 8:05 AM, Kai Tietz wrote:
  As I said before ... you need to add the target-lib/ folder to you
 path.
 

 That is unfriendly to the end-user.  Note the discussion deals with
 more than just GCC it is a deployment of the client code using GCC
 that is in discussion.  Businesses will not like your product very
 well if you have to go configure the client PC using it.

  For the host-binaries in /bin it might be good to have host DLLs
  used by it in the same directory.  But this is just true for host ==
  target and if you have just one target.

 Again the segregation is needed for the executable if you supply both
 a 32bit and a 64bit version in the same deployment.  So taking a clue
 from the Windows/ directory sysnative/ contains the binaries for the
 64bit versions and syswow64 contains the 32bit versions that run under
 the emulator.  So MyApp/bin contains the native 64bit version and
 MyApp/bin32 contains the 32bit versions and MyApp must provide a
 manifest so Windows OS knows which is which.


Why does this setup need a manifest at all? The way you describe it,
Windows will load the proper DLLs regardless...

Ruben


 The associated DLL would
 go to the same directories for convenience to the user.

 --
 Earnie
 -- https://sites.google.com/site/earnieboyd


 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

On Tue, Nov 13, 2012 at 8:23 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2012/11/13 Earnie Boyd ear...@users.sourceforge.net

 On Tue, Nov 13, 2012 at 8:05 AM, Kai Tietz wrote:
  As I said before ... you need to add the target-lib/ folder to you
  path.
 

 That is unfriendly to the end-user.  Note the discussion deals with
 more than just GCC it is a deployment of the client code using GCC
 that is in discussion.  Businesses will not like your product very
 well if you have to go configure the client PC using it.

  For the host-binaries in /bin it might be good to have host DLLs
  used by it in the same directory.  But this is just true for host ==
  target and if you have just one target.

 Again the segregation is needed for the executable if you supply both
 a 32bit and a 64bit version in the same deployment.  So taking a clue
 from the Windows/ directory sysnative/ contains the binaries for the
 64bit versions and syswow64 contains the 32bit versions that run under
 the emulator.  So MyApp/bin contains the native 64bit version and
 MyApp/bin32 contains the 32bit versions and MyApp must provide a
 manifest so Windows OS knows which is which.


 Why does this setup need a manifest at all? The way you describe it, Windows
 will load the proper DLLs regardless...

For the side-by-side assembly.  Crossing boundaries of 32bit SysWOW64
emulator into 64bit native space and vice versa will give you an
error.  The manifest will keep the two from butting heads.

--
Earnie
-- https://sites.google.com/site/earnieboyd

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

2012/11/13 Earnie Boyd ear...@users.sourceforge.net

 On Tue, Nov 13, 2012 at 8:23 AM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2012/11/13 Earnie Boyd ear...@users.sourceforge.net
 
  On Tue, Nov 13, 2012 at 8:05 AM, Kai Tietz wrote:
   As I said before ... you need to add the target-lib/ folder to you
   path.
  
 
  That is unfriendly to the end-user.  Note the discussion deals with
  more than just GCC it is a deployment of the client code using GCC
  that is in discussion.  Businesses will not like your product very
  well if you have to go configure the client PC using it.
 
   For the host-binaries in /bin it might be good to have host DLLs
   used by it in the same directory.  But this is just true for host ==
   target and if you have just one target.
 
  Again the segregation is needed for the executable if you supply both
  a 32bit and a 64bit version in the same deployment.  So taking a clue
  from the Windows/ directory sysnative/ contains the binaries for the
  64bit versions and syswow64 contains the 32bit versions that run under
  the emulator.  So MyApp/bin contains the native 64bit version and
  MyApp/bin32 contains the 32bit versions and MyApp must provide a
  manifest so Windows OS knows which is which.
 
 
  Why does this setup need a manifest at all? The way you describe it,
 Windows
  will load the proper DLLs regardless...

 For the side-by-side assembly.  Crossing boundaries of 32bit SysWOW64
 emulator into 64bit native space and vice versa will give you an
 error.  The manifest will keep the two from butting heads.


Euh... You cannot load a 32-bit DLL in a 64-bit process, or vice versa. The
only side-by-side assembly I know of is the way winsxs handles all the
slight variations of msvcr*.dll versions, and that's not related to
architecture at all.

When the 32-bit executable is loaded, the OS looks in the exe's directory
for DLLs (along with everywhere else it normally looks), loads them (skips
the 64-bit ones), and moves on. Idem ditto for the 64-bit executable.

So even if PATH looked like this:
C:\bin64;C:\bin32

where a 64-bit libgcc_s_sjlj-1.dll is in bin64 and a 32-bit one (with the
same name) is in bin32, loading a 32-bit app depending on this DLL will
never cause a problem.

I must be misunderstanding what you're trying to say.

Ruben


 --
 Earnie
 -- https://sites.google.com/site/earnieboyd


 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

On Tue, Nov 13, 2012 at 8:01 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2012/11/13 Earnie Boyd ear...@users.sourceforge.net

 That doesn't address the side-by-side issue where we need a 32bit
 executable matching the 64bit executable.  What do you propose for
 32bit executable path versus the 64bit executable path?  The reason to
 install the DLL into the bin/ directory is that the system will find
 it even if the directory isn't in PATH.  Suppose I execute a binary
 via an absolute path, one expects it to work regardless of the PATH
 variable.  There are methods (such as mucking with the KnownDLL
 registry entry, via a manifest, etc) that will allow you to move those
 DLL elsewhere but because we are on Windows, it is best to follow the
 default standard as recommended by the maker of the OS and it may be
 different for differing versions of the OS.


 http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa376414(v=vs.85).aspx


 Oh yes, let's impose a unnecessarily complicated, proprietary, non-portable
 (across OS versions) scheme on the developers/users to account for a case
 which virtually never happens (installing 32 and 64-bit executables
 alongside each other)


When in Rome ...

 Windows was never designed to be monolithic (wrt 32 and 64-bit)... Just look
 at the system32 and sysWoW64 directory in C:\Windows. Install differing
 architectures side by side, not mucked with manifests that overcomplicate
 things.


Actually System32 is a magical directory that when executing in 32bit
emulation mode is mapped to SysWOW64 and the original System32
directory is mapped to SysNative/.  This allows binaries accessing
System32 directly to DTRT.  The SysNative/ pseudo directory doesn't
exist outside of the SysWOW64 emulation.

 To execute a binary in the scheme Kai suggests, either the relevant DLL
 needs to be copied (which has to be done to install to an end-user's system
 anyways) or you set the PATH on the development machine.


Yes, true.

 To be honest, this is the mess I completely avoid by having to seperate
 build directories and toolchains for all my stuff, one per bitness. I know
 this isn't very future-friendly, but hey, I don't want to muck with too much
 muck ;-)


Which is what I said you must do; segregate the bitness differences.
But I'm still stating that the DLL belongs in the executable
directory.

--
Earnie
-- https://sites.google.com/site/earnieboyd

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?

2012/11/13 Earnie Boyd ear...@users.sourceforge.net

 On Tue, Nov 13, 2012 at 8:01 AM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2012/11/13 Earnie Boyd ear...@users.sourceforge.net
 
  That doesn't address the side-by-side issue where we need a 32bit
  executable matching the 64bit executable.  What do you propose for
  32bit executable path versus the 64bit executable path?  The reason to
  install the DLL into the bin/ directory is that the system will find
  it even if the directory isn't in PATH.  Suppose I execute a binary
  via an absolute path, one expects it to work regardless of the PATH
  variable.  There are methods (such as mucking with the KnownDLL
  registry entry, via a manifest, etc) that will allow you to move those
  DLL elsewhere but because we are on Windows, it is best to follow the
  default standard as recommended by the maker of the OS and it may be
  different for differing versions of the OS.
 
 
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
 
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/aa376414(v=vs.85).aspx
 
 
  Oh yes, let's impose a unnecessarily complicated, proprietary,
 non-portable
  (across OS versions) scheme on the developers/users to account for a case
  which virtually never happens (installing 32 and 64-bit executables
  alongside each other)
 

 When in Rome ...

  Windows was never designed to be monolithic (wrt 32 and 64-bit)... Just
 look
  at the system32 and sysWoW64 directory in C:\Windows. Install differing
  architectures side by side, not mucked with manifests that overcomplicate
  things.
 

 Actually System32 is a magical directory that when executing in 32bit
 emulation mode is mapped to SysWOW64 and the original System32
 directory is mapped to SysNative/.  This allows binaries accessing
 System32 directly to DTRT.  The SysNative/ pseudo directory doesn't
 exist outside of the SysWOW64 emulation.

  To execute a binary in the scheme Kai suggests, either the relevant DLL
  needs to be copied (which has to be done to install to an end-user's
 system
  anyways) or you set the PATH on the development machine.
 

 Yes, true.

  To be honest, this is the mess I completely avoid by having to seperate
  build directories and toolchains for all my stuff, one per bitness. I
 know
  this isn't very future-friendly, but hey, I don't want to muck with too
 much
  muck ;-)
 

 Which is what I said you must do; segregate the bitness differences.
 But I'm still stating that the DLL belongs in the executable
 directory.


OK, so we sort of understand each other ;-). For all 3rd party stuffs, I
agree, as I said. For a multilib toolchain, consistency demands both
bitness runtime DLL's are in TARGET/lib or TARGET/bin. The toolchain itself
must be built statically to avoid IDEs calling executables directly failing
to work. In order to run an exe in a development context, add TARGET/lib to
PATH and be done with it. In an end-user install context, place the DLLs
alongside the matching executables.

Simple as that :).

Ruben

PS: the opinions expressed in this email do not necessarily coincide with
the opinions of the MinGW-w64 developers, Microsoft, or any other person
participating in this discussion ;-)


 --
 Earnie
 -- https://sites.google.com/site/earnieboyd


 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Tue, Nov 13, 2012 at 2:13 PM, Kai Tietz ktiet...@googlemail.com wrote:
2012/11/13 Corinna Vinschen vinsc...@redhat.com:
On Nov 13 13:09, Ozkan Sezer wrote:
On Tue, Nov 13, 2012 at 1:03 PM, Corinna Vinschen vinsc...@redhat.com
wrote:
On Nov 13 12:17, Ozkan Sezer wrote:
On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen vinsc...@redhat.com
wrote:
On Nov 13 09:21, Kai Tietz wrote:
Hi,78

2012/11/12 Corinna Vinschen vinsc...@redhat.com:
Hi,

the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION
and
adds a definition of SYSTEM_PAGEFILE_INFORMATION and
SystemPagefileInformation. It also changes the formatting of
SYSTEM_INFORMATION_CLASS to make it a bit more readable. Tested on
32
and 64 bit.

Ok to apply?

Ok, thanks. Please apply.

Thanks, done.

As I wrote in my OP, I tested the stuff on 32 and 64 bit systems using
my very own, self-written testcase. Given that SYSTEM_BASIC_INFORMATION
was already fully available in winternl.h,

This ...

and given that the only
change I made was to change the data types to match 64 bit, and given
that I tested the result for consistency, I don't quite see your point...

... is my point: I don't have an objection againt your correction, I have
an objection against its full form being present in the first place.

Anyway, that means the idea to move the (used and tested) definitions
from Cygwin to Mingw64 is moot.

Well, I would welcome it as long as fields are proven OS-idependent or
showing real use-cases in applications using our winternl header. And
I think that cygwin as user is a vaild case, isn't it?

But I strongly agree to Ozkan that we don't want to have
NDK-definitions here. At least for now I see the burden to test all
cases as not sensible ... but well, I might be wrong

Sounds like an OK idea tome, too.

Regards,
Kai

--
O.S.

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Nov 13 13:13, Kai Tietz wrote:
 2012/11/13 Corinna Vinschen vinsc...@redhat.com:
  On Nov 13 13:09, Ozkan Sezer wrote:
  ... is my point: I don't have an objection againt your correction, I have
  an objection against its full form being present in the first place.
 
  So you want to keep winternl.h as close to upstream as possible, thus
  removing already available (and tested) definitions?  Personally I don't
  think it makes a lot of sense to keep a Reserved1 field intact, just
  because it's not documented.  Nobody *has* to use the undocumented
  fields, after all.
 
  Anyway, that means the idea to move the (used and tested) definitions
  from Cygwin to Mingw64 is moot.
 
 Well, I would welcome it as long as fields are proven OS-idependent or
 showing real use-cases in applications using our winternl header.  And
 I think that cygwin as user is a vaild case, isn't it?

That makes sense.  Unfortunately Cygwin tests the value of a PEB member
with an OS-dependent name at one point, but otherwise we only use
OS-independent stuff, afaik.

 But I strongly agree to Ozkan that we don't want to have
 NDK-definitions here.  At least for now I see the burden to test all
 cases as not sensible ... but well, I might be wrong

I have to admit that I have no idea what constitutes the difference
between an NDK-definition and, well, any other kind of definition...

  Alternatively, what about having two definitions for each datatype?  One
  of them the default, close to the MS definition, the other one if you
  define __WINTERNL_ENABLE_UNDOCUMENTED.  This would also guard the
  officially entirely undocumented datastructures.
 
 Hmm, this sounds like a nice idea.  But I would think that it might be
 better to have a switch which forces MS' PSDK mode and having
 extensions enables by default - at least as long as normal use-case is
 unaffected by it and our users might have an advantage by it.

To me the advantage is that we have a chance to unify the definitions
used from user-space and put them into a single file.  If it turns out
that a definition hasn't been tested enough and must be changed, there's
a single point to change it and every user of Mingw64 can profit right
away.


Corinna

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Mass rebuild report for November 13 2012

2012-11-13 Thread Erik van Pienbroek

This is a report for the 20121113 mass rebuild of all Fedora MinGW
packages against Fedora Rawhide and a list of all the changes which have been
applied since the previous mass rebuild.

During this mass rebuild the following toolchain was used:

* mingw-w64 20121110 trunk snapshot
* binutils 2.22.52.0.4
* gcc 4.7.2

Statistics about current mass rebuild:
--
Timestamp of mass rebuild: 20121113
Total packages: 150
Number of failed packages: 1
Number of succeeded packages: 149
Number of added packages since previous mass rebuild: 0
Time needed to perform mass rebuild: 30 hours, 19 minutes, 3 seconds

Statistics about previous mass rebuild:
---
Timestamp of previous mass rebuild: 20121106
Total packages: 150
Number of failed packages: 3
Number of succeeded packages: 147

===

The following packages were updated since the previous rebuild:

mingw-crt-2.0.999-0.15.trunk.20121110.fc19
---
* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 
2.0.999-0.15.trunk.20121110
- Update to 20121110 snapshot

* Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 
2.0.999-0.14.trunk.20121109
- Update to 20121109 snapshot


mingw-filesystem-96-2.fc19
---
* Sat Nov 10 2012 Kalev Lember kalevlem...@gmail.com - 96-2
- Add provides for mscoree.dll and regenerate the standard-dlls file


mingw-glib2-2.35.1-1.fc19
--
* Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.35.1-1
- Update to 2.35.1


mingw-gnutls-2.12.21-1.fc19

* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.12.21-1
- Update to 2.12.21


mingw-gtk3-3.7.0-1.fc19

* Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 3.7.0-1
- Update to 3.7.0


mingw-headers-2.0.999-0.15.trunk.20121110.fc19
---
* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 
2.0.999-0.15.trunk.20121110
- Update to 20121110 snapshot
- Fixes build issue with DirectWrite support in mingw-qt5-qtbase

* Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 
2.0.999-0.14.trunk.20121109
- Update to 20121109 snapshot


mingw-libtasn1-2.14-1.fc19
---
* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 2.14-1
- Update to 2.14


mingw-openssl-1.0.1c-1.fc19

* Fri Nov 09 2012 Erik van Pienbroek epien...@fedoraproject.org - 1.0.1c-1
- Update to 1.0.1c
- Synced patches with native openssl-1.0.1c-7.fc19


mingw-qt-4.8.3-3.fc19
--
* Sun Nov 04 2012 Erik van Pienbroek epien...@fedoraproject.org - 4.8.3-3
- Don't automatically strip debugging symbols from binaries created using qmake
  as we've got RPM wrapper strips to automatically split off debugging symbols
  to a separate debuginfo subpackage
- Make sure linking against the static QtUiTools library works out-of-the-box


mingw-qt5-qt3d-5.0.0-0.2.beta1.git2012.e4d3ccac.fc19
-
* Sun Nov 11 2012 Erik van Pienbroek epien...@fedoraproject.org - 
5.0.0-0.2.beta1.git2012.e4d3ccac
- Update to 2012 snapshot (rev e4d3ccac)
- Rebuild against latest mingw-qt5-qtbase
- Dropped pkg-config rename hack as it's unneeded now


mingw-qt5-qtactiveqt-5.0.0-0.2.beta1.git2012.435fac3b.fc19
---
* Sun Nov 11 2012 Erik van Pienbroek epien...@fedoraproject.org - 
5.0.0-0.2.beta1.git2012.435fac3b
- Update to 2012 snapshot (rev 4cbcad7f)
- Rebuild against latest mingw-qt5-qtbase


mingw-qt5-qtbase-5.0.0-0.13.beta1.git20121110.d725239c.fc19

* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 
5.0.0-0.13.beta1.git20121110.d725239c
- Update to 20121110 snapshot (rev d725239c)
- Dropped the configure argument -qtlibinfix 5 as upstream
  has resolved the file conflicts with Qt4 properly now
- Added several missing flags to the mkspecs profiles
- Dropped the pkg-config file renames as they're not needed any more
- Dropped two obsolete patches

* Sat Nov 10 2012 Erik van Pienbroek epien...@fedoraproject.org - 
5.0.0-0.12.beta1.git20121103.ccc4fbdf
- Update to 20121103 snapshot (rev ccc4fbdf)
- Use -std=c++11 instead of -std=c++0x as the latter is deprecated in gcc 4.7
- Added DirectWrite support
- Added Angle support


mingw-qt5-qtconnectivity-5.0.0-0.2.beta1.git20121112.63139e83.fc19
---
* Mon Nov 12 2012 Erik van Pienbroek epien...@fedoraproject.org - 
5.0.0-0.2.beta1.git20121112.63139e83
- Update to 20121112 snapshot (rev 63139e83)
- Rebuild against latest mingw-qt5-qtbase
- Dropped pkg-config rename hack as it's

Re: [Mingw-w64-public] Too many secions [was: File too big]

2012-11-13 Thread Václav Šmilauer

 I will try to do that, thanks for advice. It is a bit tedious, and many
 templates are declared in headers, so I am not sure how far I will get
 with that.
For the record, I compared -Os and -O2 options in gcc - they differ only 
in -fintline-functions (enabled with -Os, disabled with -O2) and 
-foptimize-strlen (disabled with -Os, enabled with -O2). OTOH -O3 turns 
-finline-functions on again (along with many other), so I was able to 
compile with -O3 just fine.

It seems therefore that using -finline-functions for heavy-template code 
is the way to go - I imagine a new section is created for each template 
instantiation; since most of those functions are small and get only 
called one or twice (serialization code), they can be effectively 
inlined and need no additional sections afterwards.

Cheers, Vaclav


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On Nov 13 16:32, Ozkan Sezer wrote:
 On Mon, Nov 12, 2012 at 7:37 PM, Corinna Vinschen vinsc...@redhat.com wrote:
 
 About the correction made in SYSTEM_BASIC_INFORMATION:
 
 [...]
  Index: winternl.h
  ===
  --- winternl.h  (revision 5451)
  +++ winternl.h  (working copy)
  @@ -688,9 +688,9 @@
   ULONG LowestPhysicalPage;
   ULONG HighestPhysicalPage;
   ULONG AllocationGranularity;
  -ULONG LowestUserAddress;
  -ULONG HighestUserAddress;
  -ULONG ActiveProcessors;
  +ULONG_PTR LowestUserAddress;
  +ULONG_PTR HighestUserAddress;
  +ULONG_PTR ActiveProcessors;
   CCHAR NumberOfProcessors;
 } SYSTEM_BASIC_INFORMATION,*PSYSTEM_BASIC_INFORMATION;
 
 If we compare original structure, we have:
 
   BYTE Reserved1[24];
   PVOID Reserved2[4];
   CCHAR NumberOfProcessors;
 
 So, PVOID Reserved2[4] should correspond to 4 ULONG_PTR members
 in the detailed version: do we not need the following, too?
 
 -  ULONG AllocationGranularity;
 +  ULONG_PTR AllocationGranularity;

No, the AllocationGranularity is a ULONG value.  The size of the
structure is a result of the automatic 8 byte alignment of 8 byte types.
Try this:

=== SNIP ===
#include stdio.h
#include string.h
#include windows.h

#ifndef NT_SUCCESS
#define NT_SUCCESS(status)  ((NTSTATUS) (status) = 0)
#endif

typedef int NTSTATUS;

typedef struct _SYSTEM_BASIC_INFORMATION
{
  ULONG Unknown;
  ULONG MaximumIncrement;
  ULONG PhysicalPageSize;
  ULONG NumberOfPhysicalPages;
  ULONG LowestPhysicalPage;
  ULONG HighestPhysicalPage;
  ULONG AllocationGranularity;
#ifdef _WIN64
  ULONG dummy1;
#endif
  ULONG_PTR LowestUserAddress;
  ULONG_PTR HighestUserAddress;
  ULONG_PTR ActiveProcessors;
  UCHAR NumberProcessors;
} SYSTEM_BASIC_INFORMATION, *PSYSTEM_BASIC_INFORMATION;

NTSTATUS NTAPI NtQuerySystemInformation (ULONG, PVOID, ULONG, PULONG);

int
main ()
{
  NTSTATUS status;
  ULONG i, size;
  SYSTEM_BASIC_INFORMATION sbi;

  memset (sbi, 0xbf, sizeof sbi);
  status = NtQuerySystemInformation (0, sbi, sizeof sbi, size);
  if (!NT_SUCCESS (status))
{
  fprintf (stderr, NtQuerySystemInformation: 0x%lx\n, status);
  return 1;
}
  printf (Size: %lu\n, size);
  printf (AllocationGranularity: %lu\n, sbi.AllocationGranularity);
#ifdef _WIN64
  printf (dummy1: 0x%lx\n, sbi.dummy1);
#endif
  return 0;
}
=== SNAP ===

$ x86_64-w64-mingw32-gcc -g -o sbi sbi.c -lntdll
$ ./sbi
Size: 64
AllocationGranularity: 65536
dummy1: 0xbfbfbfbf


Corinna

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for November 13 2012

2012-11-13 Thread JonY

On 11/13/2012 21:44, Erik van Pienbroek wrote:
 This is a report for the 20121113 mass rebuild of all Fedora MinGW
 packages against Fedora Rawhide and a list of all the changes which have been
 applied since the previous mass rebuild.
 
 During this mass rebuild the following toolchain was used:
 
 * mingw-w64 20121110 trunk snapshot
 * binutils 2.22.52.0.4
 * gcc 4.7.2
 
 Statistics about current mass rebuild:
 --
 Timestamp of mass rebuild: 20121113
 Total packages: 150
 Number of failed packages: 1
 Number of succeeded packages: 149
 Number of added packages since previous mass rebuild: 0
 Time needed to perform mass rebuild: 30 hours, 19 minutes, 3 seconds
 

Nice, thanks for posting this.





signature.asc
Description: OpenPGP digital signature
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION

On 11/13/12, Corinna Vinschen vinsc...@redhat.com wrote:
 On Nov 13 16:32, Ozkan Sezer wrote:
 On Mon, Nov 12, 2012 at 7:37 PM, Corinna Vinschen vinsc...@redhat.com
 wrote:

 About the correction made in SYSTEM_BASIC_INFORMATION:

 [...]
  Index: winternl.h
  ===
  --- winternl.h  (revision 5451)
  +++ winternl.h  (working copy)
  @@ -688,9 +688,9 @@
   ULONG LowestPhysicalPage;
   ULONG HighestPhysicalPage;
   ULONG AllocationGranularity;
  -ULONG LowestUserAddress;
  -ULONG HighestUserAddress;
  -ULONG ActiveProcessors;
  +ULONG_PTR LowestUserAddress;
  +ULONG_PTR HighestUserAddress;
  +ULONG_PTR ActiveProcessors;
   CCHAR NumberOfProcessors;
 } SYSTEM_BASIC_INFORMATION,*PSYSTEM_BASIC_INFORMATION;

 If we compare original structure, we have:

   BYTE Reserved1[24];
   PVOID Reserved2[4];
   CCHAR NumberOfProcessors;

 So, PVOID Reserved2[4] should correspond to 4 ULONG_PTR members
 in the detailed version: do we not need the following, too?

 -  ULONG AllocationGranularity;
 +  ULONG_PTR AllocationGranularity;

 No, the AllocationGranularity is a ULONG value.  The size of the
 structure is a result of the automatic 8 byte alignment of 8 byte types.
 Try this:

 === SNIP ===
 #include stdio.h
 #include string.h
 #include windows.h

 #ifndef NT_SUCCESS
 #define NT_SUCCESS(status)  ((NTSTATUS) (status) = 0)
 #endif

 typedef int NTSTATUS;

 typedef struct _SYSTEM_BASIC_INFORMATION
 {
   ULONG Unknown;
   ULONG MaximumIncrement;
   ULONG PhysicalPageSize;
   ULONG NumberOfPhysicalPages;
   ULONG LowestPhysicalPage;
   ULONG HighestPhysicalPage;
   ULONG AllocationGranularity;
 #ifdef _WIN64
   ULONG dummy1;
 #endif
   ULONG_PTR LowestUserAddress;
   ULONG_PTR HighestUserAddress;
   ULONG_PTR ActiveProcessors;
   UCHAR NumberProcessors;
 } SYSTEM_BASIC_INFORMATION, *PSYSTEM_BASIC_INFORMATION;

 NTSTATUS NTAPI NtQuerySystemInformation (ULONG, PVOID, ULONG, PULONG);

 int
 main ()
 {
   NTSTATUS status;
   ULONG i, size;
   SYSTEM_BASIC_INFORMATION sbi;

   memset (sbi, 0xbf, sizeof sbi);
   status = NtQuerySystemInformation (0, sbi, sizeof sbi, size);
   if (!NT_SUCCESS (status))
 {
   fprintf (stderr, NtQuerySystemInformation: 0x%lx\n, status);
   return 1;
 }
   printf (Size: %lu\n, size);
   printf (AllocationGranularity: %lu\n, sbi.AllocationGranularity);
 #ifdef _WIN64
   printf (dummy1: 0x%lx\n, sbi.dummy1);
 #endif
   return 0;
 }
 === SNAP ===

 $ x86_64-w64-mingw32-gcc -g -o sbi sbi.c -lntdll
 $ ./sbi
 Size: 64
 AllocationGranularity: 65536
 dummy1: 0xbfbfbfbf


I see.  Thanks.


 Corinna


--
O.S.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Directory for library installation: lib/ or bin/ ?