Nabble - MinGW - Dev

Re: Upcoming mingwrt release

2009-11-25T07:00:44Z

On Wed, 25 Nov 2009 09:51 -0500, "Chris Sutcliffe" <ir0nh34d@...>
wrote:
> Chuck, is there anything you have coming down the pipe that I should
> hold off for?

No, not on my end.

Not that this should affect the upcoming release at all, being a
security fix, but has there been any progress on trying to consolidate
mingwrt with the mingw64 guys?

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Upcoming mingwrt release

2009-11-25T06:51:35Z

Hey All,

Just a heads up, I plan on releasing a new mingwrt this weekend to
address this issue I cherry picked from the latest Cygwin release
notes:

* mingwex/gdtoa/misc.c: Fix security vulnerability in gdtoa:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0689

It affects libc (I assume newlib) as well mingwex. I will be
committing the change to CVS on the weekend (on the road at the moment
and I can't get CVS to work through the firewalls I'm behind).

Chuck, is there anything you have coming down the pipe that I should
hold off for?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: w32api patches

2009-11-19T05:07:28Z

Hi All,

I think I choose my example poorly (being the IActiveDesktop patch),
my point was more what alternate sites would we accept as being a
valid source (i.e. social.msdn.microsoft.com).

> Furthermore, going back to the original tracker item, the follow up
> suggests that IID_IActiveDesktop is the only questionable value, yet
> in the patch itself I see many other #defines, for which I can find
> no documentary support on MSDN, or indeed even easily elsewhere.

I perhaps wasn't overly clear in my response on the tracker item
either. I know from previous experience the IID_* values are
typically very hard to uncover (many are not in the Windows registry),
so my initial verification of the patch only included the GUID_* and
IID_* checks, I didn't go to the level of the defines yet.

Given the age of the current w32api I am pushing to hopefully get a
new release out this weekend, as such, I will leave the more
controversial patches out of this release. Once we come to agreement
on what sources we will accept for patches, I will re-evaluate those
patches.

Cheers,

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: liblzma-4.999.9beta-1 broken w.r.t. static vs. dynamic linking

2009-11-18T12:42:05Z

[skip down to the end for a compromise idea]

Keith Marshall wrote:
> Okay, I can live with LZMA_API_CALL being __cdecl; it's the default
> anyway, so mostly redundant for MinGW. However, LZMA_API_IMPORT is
> just as broken for MinGW as it is for Cygwin; IMO, and contradicting
> the comment in the header, most developers will *always* need to (or
> at least should) define LZMA_API_STATIC. Yuk!

Not exactly. Lasse is coming from the position (common on Windows) that
linking to a DLL is the default choice; linking statically is "weird".
This is probably true for commercial win32 compilers; if you snoop
around in commercial software packages you'll find lots of "libz.dll"
and such. If EVER there was a tiny library that could be linked in
statically, it's libz...

So, Lasse has chosen to treat mingw the same as commercial compilers --
because, in his view, mingw is just a tool to compile the necessary DLL
that can then be USED by "everybody". [*] Therefore, expecting
autoimport compatibility is a no-no.

[*] In fact, you can't compile liblzma using MSVC at all -- as xz
requires a C99 compiler. So, while the header files can be used by C89
(e.g. MSVC), you have to compile the DLL using mingw! IMO, then, mixing
object code (e.g. a mingw-produced liblzma.a with a MSVC-compiled
client) is such a bad idea, that it makes sense -- from the standpoint
of supporting commercial win32 compilers -- to default to DLL-centric
operation on win32.

Cygwin can get away with "special handling" -- e.g. opting out of this
win32 madness -- because there is no expectation that a cygwin-built DLL
or .a will be usable by anything other than the cygwin toolchain.

> As a consequence, (and lest I forget the reasoning), I have added
> this comment in the streaming code header for mingw-get:
>
> /* Compressed data stream classes...
> */
> #include <zlib.h>
> #include <bzlib.h>
> #ifdef __GNUC__
> /*
> * lzma.h is broken w.r.t. static vs. dynamic linking; it always
> * declares all functions with the dllimport attribute, making it
> * impossible to link with a static liblzma.a, either by using GNU
> * ld's -Bstatic option in the presence of co-existing liblzma.a
> * static and liblzma.dll.a import libraries, or in the case where
> * the import library is not installed. To work around this defect,
> * we MUST declare LZMA_API_STATIC before we include lzma.h. This
> * DOES NOT in any way interfere with GNU ld's default preference
> * for dynamic linking; this will still be the effective linking
> * mode if the import library is present, and the -Bstatic option
> * is not specified.
> */
> # define LZMA_API_STATIC 1
> #endif
> #include <lzma.h>

Shorter, less inflammatory version:

/*
* We want to link against liblzma statically. The mingw port of
* liblzma does not support transparent, interoperable static/dynamic
* linking via the traditional mechanisms provided by gcc and GNU ld;
* instead, it uses the standard commercial win32 compiler approach of
* requiring special compile-time #defines to control explicit symbol
* decoration. Unfortunately, the liblzma developers have chosen, on
* win32 platforms, to make dll-imported symbols the default symbol
* decoration mode. Thus, to link statically, we must define a
* special compile-time macro before including lzma.h:
*/
# define LZMA_API_STATIC 1

> Chuck, I know you have dealt with Lasse Collin in the past; would you
> like to raise this with him? Alternatively, should we just make the
> necessary changes in our own distribution, (so creating a less than
> desireable fork)?

I've already addressed the issue with him; his rationale is
understandable even if I don't fully agree with it, and I doubt he will
change it. There's really two issues here:

1) Use (or not) explicit declspec attributes
1a) This is NOT a choice if you want the headers to be usable with MSVC
(or intelcc, watcomcc, etc). You have to use (or not use) explicit
declspec(dllimport). And you have to turn them on (or off) via
compile-time #defines.
1b) For mingw, we'd be free to NOT use explicit markers -- except for
the additional headache that Lasse considers mingw gcc a "helper
toolchain" to generate the lzma DLL/headers necessary for
MSVC/Watcom/etc clients.

So, would we have #if defined(__MINGW32__) &&
!defined(_USING_MINGW_AS_HELPER_)?

Ick. Ok, so we're stuck using magic compile-time macros.

2) We could still get away with "normal" gcc/ld behavior if the
*default* setting was so-called "static linking". That is, on mingw
(whether "real" mingw, or mingw-as-helper), by default symbols were not
decorated, and you had to #define LIBLZMA_USING_DLL to get dllimport
decoration (he does appear to skip explicit dllexport decoration, since
compiling the DLL is only currently supported using mingw, and
autoEXport has no interoperability complications).

In that case, we could link against the headers without needing any
special #define, and rely on autoimport to DTRT.

But...Lasse has chosen otherwise, to support the
other-commercial-compiler case. He wants to:

A) compile an "official" liblzma-5.dll using mingw
B) distribute that DLL, the .h files, and a .def file so that clients --
from any compiler family -- can use it without special care.

The only drawback to this scheme is, as you note, it makes it
"difficult" for mingw users to link statically (where "difficult" is
defined as "I don't want to be required to use special #defines to
control static/dynamic linking at compile time, since my compiler --
unlike all other win32 compilers -- can work transparently without such
hacks")

Meh. This doesn't get me all worked up, honestly.

HOWEVER, this all only matters when you're USING the library. So, what
if we keep the current behavior if _WIN32 -- but NOT when
__CYGWIN__||__MINGW32__?

That way, clients explicitly using mingw gcc could exploit autoimport,
but all other win32 clients would (by default) get dllimport decorations?

#ifndef LZMA_API_IMPORT
# if !defined(LZMA_API_STATIC) && defined(_WIN32) &&
!defined(__CYGWIN__) && !defined(__MINGW32__)
# define LZMA_API_IMPORT __declspec(dllimport)
# else
# define LZMA_API_IMPORT
# endif
#endif

I think Lasse would probably accept that.

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

liblzma-4.999.9beta-1 broken w.r.t. static vs. dynamic linking

2009-11-18T11:11:55Z

In include/lzma.h I see:

/*
* Some systems require (or at least recommend) that the functions and
* function pointers are declared specially in the headers. LZMA_API_IMPORT
* is for importing symbols and LZMA_API_CALL is to specify calling
* convention.
*
* By default it is assumed that the application will link dynamically
* against liblzma. #define LZMA_API_STATIC in your application if you
* want to link against static liblzma. If you don't care about portability
* to operating systems like Windows, or at least don't care about linking
* against static liblzma on them, don't worry about LZMA_API_STATIC. That
* is, most developers will never need to use LZMA_API_STATIC.
*
* Cygwin is a special case on Windows. We rely on GCC doing the right thing
* and thus don't use dllimport and don't specify the calling convention.
*/
#ifndef LZMA_API_IMPORT
# if !defined(LZMA_API_STATIC) && defined(_WIN32) && !defined(__CYGWIN__)
# define LZMA_API_IMPORT __declspec(dllimport)
# else
# define LZMA_API_IMPORT
# endif
#endif

#ifndef LZMA_API_CALL
# if defined(_WIN32) && !defined(__CYGWIN__)
# define LZMA_API_CALL __cdecl
# else
# define LZMA_API_CALL
# endif
#endif

Okay, I can live with LZMA_API_CALL being __cdecl; it's the default
anyway, so mostly redundant for MinGW. However, LZMA_API_IMPORT is
just as broken for MinGW as it is for Cygwin; IMO, and contradicting
the comment in the header, most developers will *always* need to (or
at least should) define LZMA_API_STATIC. Yuk!

As a consequence, (and lest I forget the reasoning), I have added
this comment in the streaming code header for mingw-get:

/* Compressed data stream classes...
*/
#include <zlib.h>
#include <bzlib.h>
#ifdef __GNUC__
/*
* lzma.h is broken w.r.t. static vs. dynamic linking; it always
* declares all functions with the dllimport attribute, making it
* impossible to link with a static liblzma.a, either by using GNU
* ld's -Bstatic option in the presence of co-existing liblzma.a
* static and liblzma.dll.a import libraries, or in the case where
* the import library is not installed. To work around this defect,
* we MUST declare LZMA_API_STATIC before we include lzma.h. This
* DOES NOT in any way interfere with GNU ld's default preference
* for dynamic linking; this will still be the effective linking
* mode if the import library is present, and the -Bstatic option
* is not specified.
*/
# define LZMA_API_STATIC 1
#endif
#include <lzma.h>

Chuck, I know you have dealt with Lasse Collin in the past; would you
like to raise this with him? Alternatively, should we just make the
necessary changes in our own distribution, (so creating a less than
desireable fork)?

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: w32api patches

2009-11-17T08:45:07Z

Quoting Chris Sutcliffe <ir0nh34d@...>:

>> OTOH, when a 'bing' query
>> http://social.msdn.microsoft.com/Search/en-US?query=F490EB00&ac=8
>> finds the information in moderated msdn fora at microsoft.com:
>> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/450d7a4f-0a1a-43bc-acad-7030b6f34267
>> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/00349e46-b8da-4f23-b3f2-1a81c8a2933f
>> (search for 'F490EB00' in those pages), then I suppose we'd be
>> on firmer ground.
>
> Yes, these are more the kinds of links I was referring to when
> Googling. My assumption is that since they are posted on Forums that
> are supposedly moderated by Microsoft, can they be considered valid
> sources of information?
>

I'm not going to express an opinion. I am responding to say that
social.msdn.microsoft.com has the same terms of use as
msdn.microsoft.com. And to say that IIRC we have in the past used
values expressed in sample code, right or wrong, I don't really know.

--
Earnie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: w32api patches

2009-11-17T04:42:09Z

On Tuesday 17 November 2009 03:22:04 Greg Chicares wrote:

> On 2009-11-16 14:55Z, Chris Sutcliffe wrote:
> > I'm in the process of catching up on w32api patches / bug
> > reports / etc. so that I can hopefully roll a new release
> > shortly. As such there are a couple of reports (such as this
> > one:
> > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=287
> >7129&group_id=2435) and one regarding the correcting the
> > definition of some constants (which can be found quite easily
> > doing a Google search), which cannot be found on MSDN (at least
> > with the searching I've done).
>
> That tracker item includes a C program that ascertains the GUIDs
> corresponding to 'IActiveDesktop'. It uses a "clean room design".

Sorry, but I don't believe that it does. The originator of that item
openly admits that he used VS as a "spyglass" to scrutinise its own
headers. I'm still not convinced that such practice is strictly
legitimate as a clean room technique, but even if it is, what the
originator of the ticket then did is a clear violation of the clean
room ethic -- he generated the *patch* himself, in spite of having
disqualified himself by his participation in the questionable use of
VS headers to obtain the information.

For this poster's contribution to be acceptable, in terms of the
clean room ethic, he must *document* his findings -- not in the form
of code, nor on our tracker, but publicly elsewhere. Then, *we* may
use his documentation as a resource for improving MinGW, *without*
his direct participation.

IMO, we must reject this patch, and delete the patch file itself from
the ticket, for to scrutinise it would taint any other developer who
might consider pursuing this on our behalf; (hence, I disqualify
myself from further contribution in respect of this issue).

> I'm not sure we ever got comfortable with that technique--see,
> e.g.:
http://article.gmane.org/gmane.comp.gnu.mingw.devel/2619/match=clean+room

>
> > As was raised in the patch tracker, these definitions /
> > interface implementations, can be found in many different
> > "Windows API" implementations, so my question is, do we consider
> > doing a Google search "publicly available information" or are we
> > going to stick with MSDN being the only appropriate source of
> > information?
>
> I googled for
> IID_IActiveDesktop +0xF490EB00L
> and the first result begins:
> // Copyright (c) Microsoft Corporation 1995-1997
> so putting it on the web was apparently a copyright violation,
> which would prevent us from using it.

I searched just for "IID_IActiveDesktop", and nothing else; the first
hit was an MSDN reference page for VS.85, which didn't provide the
necessary value; the second was:
http://www.asmcommunity.net/board/index.php?topic=24826.0

This does give the required value, and it isn't in the code format we
require, (although it is still an alternative form of code rather
than documentation). Does that alternative form of expression
satisfy our criteria for a clean-room derived resource? I'm not
sure.

> OTOH, when a 'bing' query

I tried this...

> http://social.msdn.microsoft.com/Search/en-US?query=F490EB00&ac=8
> finds the information in moderated msdn fora at microsoft.com:

For me, it turned up this...

> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread
>/450d7a4f-0a1a-43bc-acad-7030b6f34267

...but not this...

> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread
>/00349e46-b8da-4f23-b3f2-1a81c8a2933f

> (search for 'F490EB00' in those pages), then I suppose we'd be on
> firmer ground.

Perhaps, but the problem I see with this is that you already have to
know at least a part of the GUID in question, to perform the initial
search -- how do we determine that, in a legitimate manner? Also,
in the one hit I did get, I see no definitive confirmation that the
GUID value apparent is, in fact, the particular one of interest,
(although perhaps a C# coder could deduce it; I don't know).

Furthermore, going back to the original tracker item, the follow up
suggests that IID_IActiveDesktop is the only questionable value, yet
in the patch itself I see many other #defines, for which I can find
no documentary support on MSDN, or indeed even easily elsewhere.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: w32api patches

2009-11-17T03:21:02Z

> That tracker item includes a C program that ascertains the GUIDs
> corresponding to 'IActiveDesktop'. It uses a "clean room design".
> I'm not sure we ever got comfortable with that technique--see, e.g.:
> http://article.gmane.org/gmane.comp.gnu.mingw.devel/2619/match=clean+room

Agreed, I wasn't referring so much to the OP's original method for
obtaining the values, more the link he provided to Wikipedia.

>> As was raised in the patch tracker, these definitions / interface
>> implementations, can be found in many different "Windows API"
>> implementations, so my question is, do we consider doing a Google
>> search "publicly available information" or are we going to stick with
>> MSDN being the only appropriate source of information?
>
> I googled for
> IID_IActiveDesktop +0xF490EB00L
> and the first result begins:
> // Copyright (c) Microsoft Corporation 1995-1997
> so putting it on the web was apparently a copyright violation,
> which would prevent us from using it.
>
> OTOH, when a 'bing' query
> http://social.msdn.microsoft.com/Search/en-US?query=F490EB00&ac=8
> finds the information in moderated msdn fora at microsoft.com:
> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/450d7a4f-0a1a-43bc-acad-7030b6f34267
> http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/00349e46-b8da-4f23-b3f2-1a81c8a2933f
> (search for 'F490EB00' in those pages), then I suppose we'd be
> on firmer ground.

Yes, these are more the kinds of links I was referring to when
Googling. My assumption is that since they are posted on Forums that
are supposedly moderated by Microsoft, can they be considered valid
sources of information?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: w32api patches

2009-11-16T19:22:04Z

On 2009-11-16 14:55Z, Chris Sutcliffe wrote:
> Hi All,
>
> I'm in the process of catching up on w32api patches / bug reports /
> etc. so that I can hopefully roll a new release shortly. As such
> there are a couple of reports (such as this one:
> https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2877129&group_id=2435)
> and one regarding the correcting the definition of some constants
> (which can be found quite easily doing a Google search), which cannot
> be found on MSDN (at least with the searching I've done).

That tracker item includes a C program that ascertains the GUIDs
corresponding to 'IActiveDesktop'. It uses a "clean room design".
I'm not sure we ever got comfortable with that technique--see, e.g.:
http://article.gmane.org/gmane.comp.gnu.mingw.devel/2619/match=clean+room

> As was raised in the patch tracker, these definitions / interface
> implementations, can be found in many different "Windows API"
> implementations, so my question is, do we consider doing a Google
> search "publicly available information" or are we going to stick with
> MSDN being the only appropriate source of information?

I googled for
IID_IActiveDesktop +0xF490EB00L
and the first result begins:
// Copyright (c) Microsoft Corporation 1995-1997
so putting it on the web was apparently a copyright violation,
which would prevent us from using it.

OTOH, when a 'bing' query
http://social.msdn.microsoft.com/Search/en-US?query=F490EB00&ac=8
finds the information in moderated msdn fora at microsoft.com:
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/450d7a4f-0a1a-43bc-acad-7030b6f34267
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/00349e46-b8da-4f23-b3f2-1a81c8a2933f
(search for 'F490EB00' in those pages), then I suppose we'd be
on firmer ground.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

w32api patches

2009-11-16T06:55:31Z

Hi All,

I'm in the process of catching up on w32api patches / bug reports /
etc. so that I can hopefully roll a new release shortly. As such
there are a couple of reports (such as this one:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2877129&group_id=2435)
and one regarding the correcting the definition of some constants
(which can be found quite easily doing a Google search), which cannot
be found on MSDN (at least with the searching I've done).

As was raised in the patch tracker, these definitions / interface
implementations, can be found in many different "Windows API"
implementations, so my question is, do we consider doing a Google
search "publicly available information" or are we going to stick with
MSDN being the only appropriate source of information?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-12T05:32:16Z

Earnie Boyd wrote:

> The individual source pieces can be uploaded to the server as long as
> there is a method for putting the package together; either manual
> instruction or scripted guidance. The individual source pieces will
> remain on the SourceForge server for as long as SF exists. GPL
> doesn't require the source to be put in one package; just that the
> source is deliverable to the user by the same media as the binary. It
> does require that the binary is creatable from the source in some
> fashion. So, the msys"core"-1.0.11-src tarball could be documentation
> and/or a set of scripts for creating the msys"core" package and
> install binary.

Oh, sure. But historically that's not how we've provided the -src
packages for the msys "big bundle" installers. Changing that now is
probably kinda pointless, given that we're moving toward -- and now have
all the pieces for -- a completely modularized MSYS distribution.

IMO, the "new" msysCORE -bin package I just uploaded is already the
"least divisible unit", and the corresponding -src tarball is the
minimum source unit that would satisfy the GPL for that -bin package.

Perhaps -- if mingw-get is to be much delayed -- we could release an
MSYS-1.0.11m (for "modular") installer, which simply includes the
various modular units necessary, current as of data YYYYMMDD, for a
more-or-less equivalent installation to the existing msys-1.0.11
installer. (But that line is really a dead end so I'd hate to waste
much time on it; mingw-get is the future).

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-12T05:00:21Z

Quoting Charles Wilson <cwilso11@...>:

> Earnie Boyd wrote:
>> Quoting Charles Wilson:
>>> Well, that's up to you. Me, I wouldn't bother: I don't see it as THAT
>>> big a problem -- with the trimmed-down msysCORE-base-src containing JUST
>>> the msys DLL source, it's only about 2.4M.
>>>
>>
>> Since the individual source packages are available for download, I
>> don't see any reason to include them in the MSYSCORE-base-src either.
>> Instruction may need to be given to create the packaged tough.
>
> I don't understand this. msyscore-BASE-src is already stripped down to
> just the msys DLL source code. It's msyscore-1.0.11-src.tar that
> contains the entire enchilada (and is really a misnomer: msys-1.0.11.exe
> is the big-bundle installer, and msys"core"-1.0.11.tar.bz2 is the
> big-bundle tarball -- it isn't *really* msys"CORE" at all).
>
> As of today, /THAT/ msys"core"-1.0.11-src tarball can't be "trimmed"
> anyway, because the modularized binaries' -src packages are USUALLY
> different (newer) versions than the ones included in Cesar's big-bundle
> msys-1.0.11[.exe|.tar.bz2] installer/tarball, for which the
> msyscore-1.0.11-src tarball is supposed to provide the GPL-required sources.
>

The individual source pieces can be uploaded to the server as long as
there is a method for putting the package together; either manual
instruction or scripted guidance. The individual source pieces will
remain on the SourceForge server for as long as SF exists. GPL
doesn't require the source to be put in one package; just that the
source is deliverable to the user by the same media as the binary. It
does require that the binary is creatable from the source in some
fashion. So, the msys"core"-1.0.11-src tarball could be documentation
and/or a set of scripts for creating the msys"core" package and
install binary.

--
Earnie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

New MinGW package: bsdtar (ALPHA release)

2009-11-10T18:46:33Z

I've uploaded an alpha version of bsdtar to the mingw.org sourceforge
site. It was compiled from libarchive SVN trunk (e.g. it is pre-2.8.0).
You should be able to use this tool to unpack most (all?) of the
packages at
http://sourceforge.net/projects/mingw/files/

BUT before you do that, remember the MinGW rule: if the package file has
"-mingw32-" in the name, you need to unpack into the C:\MinGW directory:
> cd C:\MinGW
> bsdtar xf [[the-package-file]]
If the package file has "-msys-" in the name, you need to unpack into
the C:\msys\1.0 directory:
> cd C:\msys\1.0
> bsdtar xf [[the-package-file]]
See this wiki page: http://www.mingw.org/PackageIdentificationHOWTO

bsdtar understands the following archive formats:
(old) tar
GNU tar
POSIX ustar
POSIX pax
cpio
zip
jar
ar
ISO 9660 cdrom images
It also groks the following compression formats:
lzma
xz
bzip2 (.bz2)
gzip (.gz)
compress (.Z)
However, see the disclaimer below.

The package can be obtained from
http://sourceforge.net/projects/mingw/files/
under the folder
MinGW Utilities/basic bsdtar/

Direct link:
http://downloads.sourceforge.net/mingw/bsdtar-2.7.900a_r1628-20091110-mingw32-alpha-bin.zip
http://downloads.sourceforge.net/mingw/bsdtar-2.7.900a_r1628-20091110-mingw32-alpha-src.tar.lzma

Contents:
bsdtar.exe
bsdtar.txt (man page, plain text format)
README-bsdtar.txt

README-bsdtar.txt file:
*********************************************************

bsdtar-2.7.900a_r1628-20091110-mingw32-alpha-bin.zip
bsdtar-2.7.900a_r1628-20091110-mingw32-alpha-src.tar.lzma
========================================================================

This build of bsdtar from libarchive is an alpha release,
taken from the libarchive SVN development tree. This build
is:
native win32
linked statically against libz (zlib), libbz2 (bzip2),
and liblzma (xz). Thus, it supports intrinsically
.tar.lzma, .tar.xz, .tar.bz2, and .tar.gz. It also
supports .iso and various other formats, but that's
not important here.

You should be able to unpack this archive, and use the included
bsdtar.exe without any other prerequisites. HOWEVER, it is an
ALPHA release. There are KNOWN ISSUES -- it fails some of its
own testsuite tests. These failures should not cause any issues
when used for the intended purpose:

unpacking MinGW/MSYS archives distributed from mingw.org
and/or http://sourceforge.net/projects/mingw/files/

If you attempt to use it for any other purpose, and it fails,
kills your cat, destroys your data, or causes marital problems,
you are on your own. In fact, that's true even if you DO use
it for its intended purpose, so let's go ahead an make that clear:

LICENSE
========================================================================

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer
in this position and unchanged.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-10T16:04:15Z

Earnie Boyd wrote:
> Quoting Charles Wilson:
>> Well, that's up to you. Me, I wouldn't bother: I don't see it as THAT
>> big a problem -- with the trimmed-down msysCORE-base-src containing JUST
>> the msys DLL source, it's only about 2.4M.
>>
>
> Since the individual source packages are available for download, I
> don't see any reason to include them in the MSYSCORE-base-src either.
> Instruction may need to be given to create the packaged tough.

I don't understand this. msyscore-BASE-src is already stripped down to
just the msys DLL source code. It's msyscore-1.0.11-src.tar that
contains the entire enchilada (and is really a misnomer: msys-1.0.11.exe
is the big-bundle installer, and msys"core"-1.0.11.tar.bz2 is the
big-bundle tarball -- it isn't *really* msys"CORE" at all).

As of today, /THAT/ msys"core"-1.0.11-src tarball can't be "trimmed"
anyway, because the modularized binaries' -src packages are USUALLY
different (newer) versions than the ones included in Cesar's big-bundle
msys-1.0.11[.exe|.tar.bz2] installer/tarball, for which the
msyscore-1.0.11-src tarball is supposed to provide the GPL-required sources.

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-10T10:16:44Z

Quoting Charles Wilson <cwilso11@...>:

>
> Well, that's up to you. Me, I wouldn't bother: I don't see it as THAT
> big a problem -- with the trimmed-down msysCORE-base-src containing JUST
> the msys DLL source, it's only about 2.4M.
>

Since the individual source packages are available for download, I
don't see any reason to include them in the MSYSCORE-base-src either.
Instruction may need to be given to create the packaged tough.

--
Earnie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-09T19:50:08Z

Cesar Strauss wrote:
> Thank you very much Chuck, I appreciate it. I am sorry I was not able to
> give much help this time.

N.P. Nothing else on this front can happen until mingw-get stabilizes,
but I didn't want the lack of a complete set of modularized packages to
hold things up once it does.

>
>> bash:
>
> I did try a quick port of the latest Cygwin version, but it did not
> behave very well at run-time. I will have to debug it sometime. Also, it
> would be good to have this Cygwin-specific igncr shell option enabled
> by default, so CRLF line endings are tolarated on input.

Right. That's more work than I wanted to attempt, at this point.
Personally, I wouldn't bother for a while: when we begin smoothing out
the rough patches that will be discovered in
(modularized-packages)+(mingw-get), it'd be nice if the number of
additional variables (bash-3.2, msys-1.0.dll changes, etc) were kept to
an absolute minimum during that process.

> Perhaps it would be a good idea for me to provide the MSYS runtime in
> its own package, separated from the basic support files. That way, if I
> need to update msys.bat, for instance, I do not need to upload the whole
> MSYS source code along with it.

Well, that's up to you. Me, I wouldn't bother: I don't see it as THAT
big a problem -- with the trimmed-down msysCORE-base-src containing JUST
the msys DLL source, it's only about 2.4M.

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-09T16:44:55Z

Charles Wilson wrote:

> As usual, you'll find the new packages at the FRS
> https://sourceforge.net/projects/mingw/files/ in the following folders:
>
> MSYS coreutils 5.97 (same as existing, just rebuilt/repacked)
> MSYS bash 3.1.17 (updated from 3.1.0)
> MSYS make 3.81 (same as existing, just rebuilt/repacked)
> MSYS core 1.0.11 [1]
>

Thank you very much Chuck, I appreciate it. I am sorry I was not able to
give much help this time.

> bash:
> ===============================
> Updated to official upstream patchlevel 17 (but still epoch 3.1. I
> didn't try to update to 3.2.x or 4.x. <shudder>).

I did try a quick port of the latest Cygwin version, but it did not
behave very well at run-time. I will have to debug it sometime. Also, it
would be good to have this Cygwin-specific igncr shell option enabled
by default, so CRLF line endings are tolarated on input.

> [1] "msys core"
> ===============================
> The "msys core" package
> msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma
> differs from the existing
> msysCORE-1.0.11-bin.tar.gz
> msysCORE-1.0.11.exe
> package in the following ways;
>
> 1) Contains only the MSYS dll and associated scripts, documentation,
> and helper programs -- that is, the stuff that is unique to MSYS,
> and is not already provided by other modularized packages.
>

Perhaps it would be a good idea for me to provide the MSYS runtime in
its own package, separated from the basic support files. That way, if I
need to update msys.bat, for instance, I do not need to upload the whole
MSYS source code along with it.

Regards,
Cesar

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Updated packages available (wave 7)

2009-11-07T20:48:23Z

Charles Wilson wrote:

> Then, exit all MSYS windows. From a cmd window (NOT msys!), do this:
>
> > cd C:\TEMP
> > copy /B bin\msys-1.0.dll C:\msys\1.0\bin
> > copy /B bin\bash.exe C:\msys\1.0\bash.exe
> > copy /B bin\sh.exe C:\msys\1.0\sh.exe

Oops:

> cd C:\TEMP
> copy /B bin\msys-1.0.dll C:\msys\1.0\bin\
> copy /B bin\bash.exe C:\msys\1.0\bin\
> copy /B bin\sh.exe C:\msys\1.0\bin\

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Updated packages available (wave 7)

2009-11-07T20:44:47Z

I've uploaded several new MSYS packages to sourceforge. As always, MSYS
packages should be unpacked under / (that is, C:\msys\1.0) and MinGW
packages should be unpacked under /mingw (that is, C:\MinGW).

As usual, you'll find the new packages at the FRS
https://sourceforge.net/projects/mingw/files/ in the following folders:

MSYS coreutils 5.97 (same as existing, just rebuilt/repacked)
MSYS bash 3.1.17 (updated from 3.1.0)
MSYS make 3.81 (same as existing, just rebuilt/repacked)
MSYS core 1.0.11 [1]

Note however, that updating 'bash' and 'core' can't be done from within
an msys environment. Instead, follow this procedure:

>From an MSYS window:

$ cd /
$ bsdtar xf bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
$ bsdtar xf msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma

Both of these commands will generate errors (unable to replace in-use
files). Next:

$ cd C:/TEMP
$ bsdtar xf bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
$ bsdtar xf msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma

Then, exit all MSYS windows. From a cmd window (NOT msys!), do this:

> cd C:\TEMP
> copy /B bin\msys-1.0.dll C:\msys\1.0\bin
> copy /B bin\bash.exe C:\msys\1.0\bash.exe
> copy /B bin\sh.exe C:\msys\1.0\sh.exe

And then clean up C:\TEMP if desired.

The new packages satisfy the latest MinGW/MSYS packaging standards,
allowing a more granular installation in keeping with the "minimal"
nature of MinGW/MSYS. See
http://www.mingw.org/PackageIdentificationHOWTO for more information.

However, until an installer capable of managing the granular selections
is available (which will happen eventually), what we have is a whole lot
of packages, which you the user have to download separately and manually
unpack. So what should you install?

Short version: You want all of these -bin packages. You might want the
coreutils-ext package, and non-english speakers might want the -lang
packages.

Some notes concerning these updates:

coreutils:
===============================
Built with i18n enabled. The translation files are packaged in a
separate -lang tarball, so native English speakers need not download
them. However, the individual tools have libiconv/libintl code linked in
statically, which makes the binaries larger. I figure this is a
reasonable tradeoff, to support non-English speakers. The size penalty
will go away, once the msys compiler is updated from 2.95.3 to 3.x or
better, which will allow us to build msys-libintl/msys-libiconv as DLLs.

The coreutils-bin package contains the tools that were originally
shipped as part of the msysCORE installation (plus echo.exe, printf.exe,
and pwd.exe -- in the original msysCORE, these were scripts. But scripts
aren't i18n-aware).

There is also a coreutils-ext package, which contains all the OTHER
coreutils executables.

make:
===============================
Built with i18n enabled. The translation files are packaged in a
separate -lang tarball, so native English speakers need not download them.

bash:
===============================
Updated to official upstream patchlevel 17 (but still epoch 3.1. I
didn't try to update to 3.2.x or 4.x. <shudder>). bash is NOT built
with i18n enabled -- because upstream bash-3.1 does not actually provide
any translations.

[1] "msys core"
===============================
The "msys core" package
msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma
differs from the existing
msysCORE-1.0.11-bin.tar.gz
msysCORE-1.0.11.exe
package in the following ways;

1) Contains only the MSYS dll and associated scripts, documentation,
and helper programs -- that is, the stuff that is unique to MSYS,
and is not already provided by other modularized packages.

2) The postinstall script has been modified to prefer the .exe's
shipped by the other -bin packages, rather than preferring wrapper
scripts. That is, prefer
awk.exe echo.exe egrep.exe ex.exe fgrep.exe
printf.exe pwd.exe rview.exe rvim.exe view.exe
to script versions (note that usually echo, printf, and pwd are
shell builtins; this change only makes a difference for those three
applications when you explicitly execute /bin/foo)

3) While you COULD generate a -bin package which these characteristics
and footprint by unpacking the associated base-src package (more
below) and running `msysbld.sh && msysrls.sh', I didn't do that. (I
tested that, and it works fine. But:) Instead, the *binaries* in
this -base-bin package are exact COPIES from the corresponding
files in the original msysCORE-1.0.11-bin.tar.gz and
msysCORE-1.0.11.exe.

Thus, except for the postinstall script differences and the
.exe-vs-script issues mentioned above, unpacking this -base-bin
tarball will give you the same binaries as the original -bin
package === FOR those binaries that -base-bin actually includes.
That is, same msys-1.0.dll, identical msysmnt.exe, etc.

Now, the -base-src package differs from the original -src package in the
following ways:

1) The original -src package included, as required by the GPL, all the
source code for the add-on packages like bash, make, coreutils,
rxvt, etc. Since -base-bin does NOT ship those binaries, the
-base-src package does not include those sources. That is:

rm -rf msysCORE-1.0.11/src/bash-3.1-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/bzip2-1.0.3-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/coreutils-5.97-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/cpmake-3.81-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/diffutils-2.8.7-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/file-4.16-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/findutils-4.3.0-MSYS-1.0.11-3
rm -rf msysCORE-1.0.11/src/gawk-3.1.5-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/grep-2.4.2-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/gzip-1.2.4a-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/less-358-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/lzma-4.43-MSYS-1.0.11-2
rm -rf msysCORE-1.0.11/src/m4-1.4.7-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/patch-2.5.4-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/rxvt-2.7.2-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/sed-3.02-MSYS-1.0.11-1
rm -rf msysCORE-1.0.11/src/tar-1.19.90-MSYS-1.0.11-2
rm -rf msysCORE-1.0.11/src/texinfo-4.11-MSYS-1.0.11-1

2) Because of the (new) preference for executables over scripts,
various files were removed from msysCORE-1.0.11/store:

rm -f msysCORE-1.0.11/store/noarch/bin/awk #[gawk-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/bunzip2 #[bzip-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/echo #[coreutils-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/egrep #[grep-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/fgrep #[grep-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/gunzip #[gzip-bin
rm -f msysCORE-1.0.11/store/noarch/bin/printf #[coreutils-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/pwd #[coreutils-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/texi2dvi #[texinfo-bin]

rm -f msysCORE-1.0.11/store/noarch/bin/d2u
#[cygutils-dos2unix-bin]
rm -f msysCORE-1.0.11/store/noarch/bin/u2d
#[cygutils-dos2unix-bin]

3) config.site is no longer appropriate (it contains mostly
workarounds for old busted libtool; new hotness libtool
doesn't need that). We don't ship it as part of msys-1.0.11
anyway. Also, /etc/termcap is now provided by the termcap-bin
package.

rm -f msysCORE-1.0.11/store/noarch/etc/config.site
rm -f msysCORE-1.0.11/store/noarch/etc/termcap

4) Fix up the packaging .dat files to account for the changes above.

msysCORE-1.0.11/store/var/dll.dat
msysCORE-1.0.11/store/var/etc.dat
msysCORE-1.0.11/store/var/exe.dat
msysCORE-1.0.11/store/var/misc.dat
msysCORE-1.0.11/store/var/script.dat
msysCORE-1.0.11/store/var/share.dat

5) Updated the build script to create the desired package name, and
to skip creating an .exe installer. Update the postinstall script
as described above.
msysCORE-1.0.11/msysrls.sh
msysCORE-1.0.11/store/noarch/pi/pi.sh

The changes in (4) and (5) are in the attached patch. We now possess
completely modularized components, suitable for installation by
mingw-get, once it is ready [*]. At some point I'll set up a wiki page
that lists exactly which packages are necessary for an installation
footprint matching
(a) the original msysCORE installation
(b) a separate list describing a basic msysCORE+msysDTK installation
(c) and yet another list describing an msysCORE+msysDTK+msysDVLPR one

[*] except for msysDVLPR. But that's ok. I imagine that setting up an
msysDVLPR environment will continue to be a manual process, even after
the advent of mingw-get.

FINAL note: if you're trying to mimic mingw-get "by hand", and want to
install msys on a pristine system using only the modularized components,
you'll have to unpack at least msyscore-bin, coreutils-bin, and bash-bin
BEFORE attempting to run /postinstall/pi.bat or pi.sh. And naturally,
you'll need to use a non-MSYS tar and lzma utility.

--
Chuck

P.S. Here's the list:

bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
bash-3.1.17-2-msys-1.0.11-doc.tar.lzma
bash-3.1.17-2-msys-1.0.11-lic.tar.lzma
bash-3.1.17-2-msys-1.0.11-src.tar.lzma
bash-3.1.17-2-msys.RELEASE_NOTES.txt

make-3.81-2-msys-1.0.11-bin.tar.lzma
make-3.81-2-msys-1.0.11-doc.tar.lzma
make-3.81-2-msys-1.0.11-lang.tar.lzma
make-3.81-2-msys-1.0.11-lic.tar.lzma
make-3.81-2-msys-1.0.11-src.tar.lzma
make-3.81-2-msys.RELEASE_NOTES.txt

coreutils-5.97-2-msys-1.0.11-bin.tar.lzma
coreutils-5.97-2-msys-1.0.11-doc.tar.lzma
coreutils-5.97-2-msys-1.0.11-ext.tar.lzma
coreutils-5.97-2-msys-1.0.11-lang.tar.lzma
coreutils-5.97-2-msys-1.0.11-lic.tar.lzma
coreutils-5.97-2-msys-1.0.11-src.tar.lzma
coreutils-5.97-2-msys.RELEASE_NOTES.txt

msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma
msysCORE-1.0.11-msys-1.0.11-base-src.tar.lzma

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

msys-core-packaging.patch.gz (2K) Download Attachment

Re: Fwd: Filetype text please for release notes on SF

2009-11-06T14:30:20Z

On Friday 06 November 2009 13:17:02 Keith Marshall wrote:
> [adding .txt extension to RELEASE-NOTES files]
>
> Obviously, since SF doesn't allow us (readily) to rename files, to
> provide this retrospectively for existing releases may entail some
> significant effort, and I'm not going to demand that anyone should
> embark on that; if anyone would care to undertake it voluntarily,
> then please step forward.

Henry has now responded with the following update...
> You not need change any, because SF has changed it now.
> The niew URL for "Notes" is with apending a "/view", and this
> works as view in browser frame.

so I guess no action is required. It may still make sense to add the
extension, for future RELEASE-NOTES files, just to make it clear that
their content is plain text.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-06T13:21:00Z

On Friday 06 November 2009 13:27:40 Earnie Boyd wrote:
> SF does have a business method for a project takeover. Maybe you
> want to pursue that, just to get the changes to the master
> source repository.

I have enough on my plate, without taking on another project.

> Then we wouldn't have to have a fork.

Well, the TinyXML deployment strategy is for every client project to
simply drop a handful of source files into its own tree, and compile
it as part of the project; every such client is potentially a fork.

That said, my comment on their developer forum did elicit a response
from Lee Thomason, (the original author), so maybe there is hope for
matching changes in the master repository.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-06T05:27:40Z

Quoting Keith Marshall <keithmarshall@...>:

> On Thursday 05 November 2009 00:31:14 John E. / TDM wrote:
>> Chris Sutcliffe wrote:
>> >> John, have you raised this issue with the tinyxml folks?
>> >>
>> >
>> > I'm not sure how actively tinyxml is being developed. The last
>> > release was over 2 years ago, as was the last commit to CVS.
>> >
>>
>> Because of this, and because it's entirely uncritical, I haven't
>> bothered.
>
> I just checked their developer forum, and their trackers. There have
> been three or four reports about this issue already; I've added a
> comment to the latest forum report, with a pointer to this thread.
> Given the apparent lack of interest among the named developers,
> beyond maintaining our own local patches, I see no point in pursuing
> it further.
>

SF does have a business method for a project takeover. Maybe you want
to pursue that, just to get the changes to the master source repository.

> BTW, on their bug tracker I did notice one item which looks more
> critical -- an invalid snprintf format specification ("%lf") which
> Microsoft (and hence MinGW) deems as synonymous with "%Lf", but
> which POSIX doesn't recognise, and could interpret as "%f". It
> affects the TiXmlAttribute::SetDoubleValue method, (which mingw-get
> doesn't currently use, AFAICT); I'll patch it anyway, in our CVS.

Then we wouldn't have to have a fork.

--
Earnie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Fwd: Filetype text please for release notes on SF

2009-11-06T05:17:02Z

Henry Nestler wrote to me privately:

> https://sourceforge.net/projects/mingw/files/ :
> If I click on "Notes/Subscribe" for latest upload of autoconf,
> then Firefox (3.5.3 under Linux) ask only where to store this
> binary (!) file.
>
> I know, that the new FRS on SF is not very user friendly for
> uploaders and downloaders too.
>
> But, you can make the accessable of "release notes" a tick better
> for users by adding file extension ".txt" to the file
> "autoconf-2.63-1-msys.RELEASE_NOTES". Than, the user can choose
> direct view in an editor.
>
> Here is an example by me:

https://sourceforge.net/projects/colinux/files/coLinux-stable/0.7.5-linux-2.6.22.18

I don't see the problem Henry reports, with Firefox-3.0.14 on my
Ubuntu-8.04-LTS box; however he may have a valid point. If simply
adding a .txt extension to RELEASE-NOTES files will improve the user
experience, I see no reason to refuse to accommodate this, at least
in the case of future package releases.

Obviously, since SF doesn't allow us (readily) to rename files, to
provide this retrospectively for existing releases may entail some
significant effort, and I'm not going to demand that anyone should
embark on that; if anyone would care to undertake it voluntarily,
then please step forward.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-05T12:28:57Z

On Thursday 05 November 2009 18:21:55 Earnie Boyd wrote:
> > - while ( *p && IsWhiteSpace( *p ) || *p == '\n' || *p =='\r'
> > ) + while ( (*p && IsWhiteSpace( *p )) || *p == '\n' || *p
> > =='\r' )
>
> This change seems wrong to me. I think the change should be the
> following instead. The reason I think this is the pointer *p
> needs tested for a value.
>
> + while ( *p && (IsWhiteSpace( *p ) || *p == '\n' || *p =='\r' ))

Yes. That's precisely the point I was making in my original post.
However, because the checks for '\n' and '\r' are already performed
in IsWhiteSpace() anyway, (and seemingly redundant there too), it is
pointless repeating them here, so I plan to change it to just:

+ while ( *p && IsWhiteSpace( *p ) )

See also my earlier follow up.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-05T10:21:55Z

Quoting Keith Marshall <keithmarshall@...>:

> - while ( *p && IsWhiteSpace( *p ) || *p == '\n' || *p =='\r' )
> + while ( (*p && IsWhiteSpace( *p )) || *p == '\n' || *p =='\r' )

This change seems wrong to me. I think the change should be the
following instead. The reason I think this is the pointer *p needs
tested for a value.

+ while ( *p && ( IsWhiteSpace( *p ) || *p == '\n' || *p =='\r' ))

--
Earnie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-05T05:58:39Z

On Thursday 05 November 2009 00:31:14 John E. / TDM wrote:

> Chris Sutcliffe wrote:
> >> John, have you raised this issue with the tinyxml folks?
> >>
> >
> > I'm not sure how actively tinyxml is being developed. The last
> > release was over 2 years ago, as was the last commit to CVS.
> >
>
> Because of this, and because it's entirely uncritical, I haven't
> bothered.

I just checked their developer forum, and their trackers. There have
been three or four reports about this issue already; I've added a
comment to the latest forum report, with a pointer to this thread.
Given the apparent lack of interest among the named developers,
beyond maintaining our own local patches, I see no point in pursuing
it further.

BTW, on their bug tracker I did notice one item which looks more
critical -- an invalid snprintf format specification ("%lf") which
Microsoft (and hence MinGW) deems as synonymous with "%Lf", but
which POSIX doesn't recognise, and could interpret as "%f". It
affects the TiXmlAttribute::SetDoubleValue method, (which mingw-get
doesn't currently use, AFAICT); I'll patch it anyway, in our CVS.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-04T16:31:14Z

Chris Sutcliffe wrote:
>> John, have you raised this issue with the tinyxml folks?
>>
>
> I'm not sure how actively tinyxml is being developed. The last
> release was over 2 years ago, as was the last commit to CVS.
>

Because of this, and because it's entirely uncritical, I haven't bothered.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-04T16:30:24Z

Keith Marshall wrote:
> In the copy of tinyxml added by John E. to the mingw-get repository,
> I see (with white space condensed) the following change from a copy
> of the upstream source:
>
*snip*

> +/* Modified: JohnE, 2008-08-09
> + * Add parentheses to fix GCC -Wall warning
> + */
> +
> #include <ctype.h>
> #include <stddef.h>
>
> @@ -354,7 +358,7 @@
> }
> else
> {
> - while ( *p && IsWhiteSpace( *p ) || *p == '\n' || *p =='\r' )
> + while ( (*p && IsWhiteSpace( *p )) || *p == '\n' || *p =='\r' )
> ++p;
> }
>
> I don't see that warning, either with MinGW g++-3.4.5 or with Ubuntu
> g++-4.2.4, but I guess it is present with later g++.

I don't know for certain when the fix became necessary, nor have I
compiled an unmodified version of TinyXML in quite a while.

> The original
> logic is certainly (perhaps harmlessly) ambiguous, but surely the
> intended expression would be:
>
> while( *p && (IsWhiteSpace( *p ) || *p == '\n' || *p == '\r') )
>
> or, since IsWhiteSpace() is defined as:
>
> inline static bool IsWhiteSpace( char c )
> {
> return (isspace( (unsigned char) c ) || c == '\n' || c == '\r');
> }
>
> (doesn't isspace() return true for '\n' and '\r' anyway?) wouldn't
>
> while( *p && IsWhiteSpace( *p ) )
>
> suffice?
>

I concur. The same conclusion was reached in discussion I witnessed for
another project.

> John, have you raised this issue with the tinyxml folks?
>

I'll reply to Chris Sutcliffe's remark on this.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: tinyxml usage in mingw-get CVS

2009-11-04T13:52:32Z

> I don't see that warning, either with MinGW g++-3.4.5 or with Ubuntu
> g++-4.2.4, but I guess it is present with later g++. The original
> logic is certainly (perhaps harmlessly) ambiguous, but surely the
> intended expression would be:

I don't see the warning with MinGW g++-4.4.0 either (I use tinyxml for
one of my other projects).

> John, have you raised this issue with the tinyxml folks?

I'm not sure how actively tinyxml is being developed. The last
release was over 2 years ago, as was the last commit to CVS.

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

tinyxml usage in mingw-get CVS

2009-11-04T08:40:49Z

In the copy of tinyxml added by John E. to the mingw-get repository,
I see (with white space condensed) the following change from a copy
of the upstream source:

--- tinyxml-upstream/tinyxmlparser.cpp ...
+++ mingw-get/tinyxml/tinyxmlparser.cpp ...
@@ -22,6 +22,10 @@
distribution.
*/

+/* Modified: JohnE, 2008-08-09
+ * Add parentheses to fix GCC -Wall warning
+ */
+
#include <ctype.h>
#include <stddef.h>

@@ -354,7 +358,7 @@
}
else
{
- while ( *p && IsWhiteSpace( *p ) || *p == '\n' || *p =='\r' )
+ while ( (*p && IsWhiteSpace( *p )) || *p == '\n' || *p =='\r' )
++p;
}

I don't see that warning, either with MinGW g++-3.4.5 or with Ubuntu
g++-4.2.4, but I guess it is present with later g++. The original
logic is certainly (perhaps harmlessly) ambiguous, but surely the
intended expression would be:

while( *p && (IsWhiteSpace( *p ) || *p == '\n' || *p == '\r') )

or, since IsWhiteSpace() is defined as:

inline static bool IsWhiteSpace( char c )
{
return (isspace( (unsigned char) c ) || c == '\n' || c == '\r');
}

(doesn't isspace() return true for '\n' and '\r' anyway?) wouldn't

while( *p && IsWhiteSpace( *p ) )

suffice?

John, have you raised this issue with the tinyxml folks?

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Sync pseudo-reloc.c, round #2

2009-11-02T04:16:56Z

Chris Sutcliffe wrote:
>> Ping? This is the last step needed to fully synchronize cygwin,
>> mingw64, and mingw32 editions of pseudo-reloc.c...
>
> Sorry, your original reply got buried in my inbox and I ended up
> skipping it somehow... Please apply this patch.

Done.

--
Chuck

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Sync pseudo-reloc.c, round #2

2009-11-01T19:46:29Z

Hey Chuck,

>> Aaaargh. While preparing the final synchronization patch for the
>> mingw64 folks, I noticed a *second* error path that I had not yet tested
>> -- and it had the same bug. The attached patch fixes that one (the
>> synchronization patch I just sent to the mingw64 guys includes this change).
>>
>> 2009-10-26 Charles Wilson <...>
>>
>> Resync with cygwin.
>> * pseudo-reloc.c (__report_error) [CYGWIN]: Correct size bug
>> regarding error messages.
>>
>> OK? (and sorry for all the churn; hopefully this is the last of it)
>
> Ping? This is the last step needed to fully synchronize cygwin,
> mingw64, and mingw32 editions of pseudo-reloc.c...

Sorry, your original reply got buried in my inbox and I ended up
skipping it somehow... Please apply this patch.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Sync pseudo-reloc.c, round #2

2009-11-01T18:36:50Z

Charles Wilson wrote:

> Aaaargh. While preparing the final synchronization patch for the
> mingw64 folks, I noticed a *second* error path that I had not yet tested
> -- and it had the same bug. The attached patch fixes that one (the
> synchronization patch I just sent to the mingw64 guys includes this change).
>
> 2009-10-26 Charles Wilson <...>
>
> Resync with cygwin.
> * pseudo-reloc.c (__report_error) [CYGWIN]: Correct size bug
> regarding error messages.
>
> OK? (and sorry for all the churn; hopefully this is the last of it)

Ping? This is the last step needed to fully synchronize cygwin,
mingw64, and mingw32 editions of pseudo-reloc.c...

--
Chuck

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

Re: Honor DESTDIR in w32api and mingw

2009-10-29T14:56:34Z

Keith Marshall wrote:

> Yes; (I guess you don't need it in `FLAGS_TO_PASS' either, since it's
> already implicit in `MAKEFLAGS'). Please feel free to commit, when
> you are ready.

As committed:

mingw ChangeLog
2009-10-29 Charles Wilson <...>

Honor DESTDIR for winsup/mingw and winsup/w32api.
Detect and report error if installation paths are win32
format, but DESTDIR is non-empty.

* Makefile.in (DESTDIR): Honor per convention.
(need-DESTDIR-compatibility): New macro; define it and a
corresponding rule.
(fail-DESTDIR-compatibility): New dependency goal.
(install-dirs): Require need-DESTDIR-compatibility.
* mingwex/Makefile.in (DESTDIR): Honor per convention.
(need-DESTDIR-compatibility): New macro; define it and a
corresponding rule.
(fail-DESTDIR-compatibility): New dependency goal.
(install): Require need-DESTDIR-compatibility.
* profile/Makefile.in: Ditto.

w32api ChangeLog
2009-10-29 Charles Wilson <...>

Honor DESTDIR for winsup/mingw and winsup/w32api.
Detect and report error if installation paths are win32
format, but DESTDIR is non-empty.

* Makefile.in (install, uninstall): Use FLAGS_TO_PASS
when invoking make in subdirs.
* lib/Makefile.in (DESTDIR): Honor per convention.
(need-DESTDIR-compatibility): New macro; define it and a
corresponding rule.
(fail-DESTDIR-compatibility): New dependency goal.
(install-libraries, install-headers, uninstall-libraries,
uninstall-headers): Require need-DESTDIR-compatibility.
* lib/ddk/Makefile.in: Ditto.
* lib/directx/Makefile.in: Ditto.

--
Chuck

Index: mingw/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/mingw/Makefile.in,v
retrieving revision 1.89
diff -u -p -r1.89 Makefile.in
--- mingw/Makefile.in 27 Jul 2009 20:27:09 -0000 1.89
+++ mingw/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -90,6 +90,7 @@ inst_bindir:=$(tooldir)/bin
inst_includedir:=$(tooldir)/include/mingw
inst_libdir:=$(tooldir)/lib/mingw
inst_docdir:=$(tooldir)/share/doc/mingw-runtime
+need-DESTDIR-compatibility = prefix exec_prefix tooldir mandir
else
ifneq (,$(with_cross_host))
#
@@ -104,11 +105,13 @@ inst_bindir:=$(tooldir)/bin
inst_includedir:=$(tooldir)/include
inst_libdir:=$(tooldir)/lib
inst_docdir:=$(tooldir)/share/doc/mingw-runtime
+need-DESTDIR-compatibility = prefix exec_prefix tooldir mandir
else
inst_bindir:=$(bindir)
inst_includedir:=$(includedir)
inst_libdir:=$(libdir)
inst_docdir:=$(prefix)/doc/runtime
+need-DESTDIR-compatibility = prefix bindir includedir libdir mandir
endif
endif

@@ -274,7 +277,7 @@ all_dlls_host: $(DLLS)

install_dlls_host:
for i in $(DLLS); do \
- $(INSTALL_PROGRAM) $$i $(inst_bindir)/$$i ; \
+ $(INSTALL_PROGRAM) $$i $(DESTDIR)$(inst_bindir)/$$i ; \
done

_libm_dummy.o:
@@ -493,25 +496,36 @@ info-html:

install-info: info

-install-dirs:
- $(mkinstalldirs) $(inst_bindir)
- $(mkinstalldirs) $(inst_includedir)
- $(mkinstalldirs) $(inst_libdir)
- $(mkinstalldirs) $(inst_docdir)
- $(mkinstalldirs) $(mandir)/man$(mansection)
+.PHONY: $(need-DESTDIR-compatibility) fail-DESTDIR-compatibility
+
+$(need-DESTDIR-compatibility):
+ @test -z "$(DESTDIR)" || case "$($@)" in ?:*) \
+ $(MAKE) --no-print-directory reject="$@" fail-DESTDIR-compatibility ;; \
+ esac
+
+fail-DESTDIR-compatibility:
+ $(error DESTDIR is not supported when $(reject) contains Win32 path `$($(reject))'; \
+ try `make install $(reject)=$(shell echo '$($(reject))' | sed s,:,:$(DESTDIR),) ...' instead)
+
+install-dirs: $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_bindir)
+ $(mkinstalldirs) $(DESTDIR)$(inst_includedir)
+ $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
+ $(mkinstalldirs) $(DESTDIR)$(inst_docdir)
+ $(mkinstalldirs) $(DESTDIR)$(mandir)/man$(mansection)

install: all install-dirs $(install_dlls_host)
for i in $(LIBS); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done
for i in $(CRT0S); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done
for i in $(INSTDOCS); do \
- $(INSTALL_DATA) $(srcdir)/$$i $(inst_docdir)/$$i ; \
+ $(INSTALL_DATA) $(srcdir)/$$i $(DESTDIR)$(inst_docdir)/$$i ; \
done
for sub in . sys ; do \
- dstdir=$(inst_includedir)/$$sub ; \
+ dstdir=$(DESTDIR)$(inst_includedir)/$$sub ; \
$(mkinstalldirs) $$dstdir ; \
for i in $(srcdir)/include/$$sub/*.h ; do \
$(INSTALL_DATA) $$i $$dstdir/`basename $$i` ; \
@@ -521,10 +535,10 @@ install: all install-dirs $(install_dlls
# This provisional hack installs the only manpage we have at present...
# It simply CANNOT suffice, when we have more manpages to ship.
#
- $(mkinstalldirs) $(mandir)/man$(mansection)
- $(INSTALL_DATA) $(srcdir)/man/dirname.man $(mandir)/man$(mansection)/`\
+ $(mkinstalldirs) $(DESTDIR)$(mandir)/man$(mansection)
+ $(INSTALL_DATA) $(srcdir)/man/dirname.man $(DESTDIR)$(mandir)/man$(mansection)/`\
echo dirname.man|sed '$(manpage_transform);s,man$$,$(mansection),'`
- $(INSTALL_DATA) $(srcdir)/man/dirname.man $(mandir)/man$(mansection)/`\
+ $(INSTALL_DATA) $(srcdir)/man/dirname.man $(DESTDIR)$(mandir)/man$(mansection)/`\
echo basename.man|sed '$(manpage_transform);s,man$$,$(mansection),'`
#
# End provisional hack.
Index: mingw/mingwex/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/mingw/mingwex/Makefile.in,v
retrieving revision 1.47
diff -u -p -r1.47 Makefile.in
--- mingw/mingwex/Makefile.in 27 Jul 2009 20:27:09 -0000 1.47
+++ mingw/mingwex/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -255,10 +255,22 @@ info-html:

install-info: info

-install: all
- $(mkinstalldirs) $(inst_libdir)
+need-DESTDIR-compatibility = prefix libdir
+.PHONY: $(need-DESTDIR-compatibility) fail-DESTDIR-compatibility
+
+$(need-DESTDIR-compatibility):
+ @test -z "$(DESTDIR)" || case "$($@)" in ?:*) \
+ $(MAKE) --no-print-directory reject="$@" fail-DESTDIR-compatibility ;; \
+ esac
+
+fail-DESTDIR-compatibility:
+ $(error DESTDIR is not supported when $(reject) contains Win32 path `$($(reject))'; \
+ try `make install $(reject)=$(shell echo '$($(reject))' | sed s,:,:$(DESTDIR),) ...' instead)
+
+install: all $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
for i in $(LIBS); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done

clean:
Index: mingw/profile/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/mingw/profile/Makefile.in,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile.in
--- mingw/profile/Makefile.in 27 Jul 2009 20:27:09 -0000 1.17
+++ mingw/profile/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -128,18 +128,30 @@ info-html:

install-info: info

-install: all
- $(mkinstalldirs) $(inst_libdir)
+need-DESTDIR-compatibility = prefix libdir includedir
+.PHONY: $(need-DESTDIR-compatibility) fail-DESTDIR-compatibility
+
+$(need-DESTDIR-compatibility):
+ @test -z "$(DESTDIR)" || case "$($@)" in ?:*) \
+ $(MAKE) --no-print-directory reject="$@" fail-DESTDIR-compatibility ;; \
+ esac
+
+fail-DESTDIR-compatibility:
+ $(error DESTDIR is not supported when $(reject) contains Win32 path `$($(reject))'; \
+ try `make install $(reject)=$(shell echo '$($(reject))' | sed s,:,:$(DESTDIR),) ...' instead)
+
+install: all $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
for i in $(LIBS); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done
for i in $(CRT0S); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done
for sub in . ; do \
- $(mkinstalldirs) $(inst_includedir)/$$sub ; \
+ $(mkinstalldirs) $(DESTDIR)$(inst_includedir)/$$sub ; \
for i in $(srcdir)/$$sub/*.h ; do \
- $(INSTALL_DATA) $$i $(inst_includedir)/$$sub/`basename $$i` ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_includedir)/$$sub/`basename $$i` ; \
done ; \
done

Index: w32api/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/Makefile.in,v
retrieving revision 1.47
diff -u -p -r1.47 Makefile.in
--- w32api/Makefile.in 6 Dec 2008 02:25:28 -0000 1.47
+++ w32api/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -89,7 +89,7 @@ test:

install uninstall:
for i in $(SUBDIRS); do \
- (cd $$i; $(MAKE) $@); \
+ (cd $$i; $(MAKE) $@ $(FLAGS_TO_PASS)); \
done

ifdef SNAPDATE
Index: w32api/lib/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/lib/Makefile.in,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile.in
--- w32api/lib/Makefile.in 29 Jan 2008 21:18:49 -0000 1.46
+++ w32api/lib/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -208,24 +208,36 @@ lib%.a: %.o
$(AR) rc $@ $*.o
$(RANLIB) $@

+need-DESTDIR-compatibility = prefix libdir includedir
+.PHONY: $(need-DESTDIR-compatibility) fail-DESTDIR-compatibility
+
+$(need-DESTDIR-compatibility):
+ @test -z "$(DESTDIR)" || case "$($@)" in ?:*) \
+ $(MAKE) --no-print-directory reject="$@" fail-DESTDIR-compatibility ;; \
+ esac
+
+fail-DESTDIR-compatibility:
+ $(error DESTDIR is not supported when $(reject) contains Win32 path `$($(reject))'; \
+ try `make install $(reject)=$(shell echo '$($(reject))' | sed s,:,:$(DESTDIR),) ...' instead)
+
.PHONY: install install-libraries install-headers install-ddk
# install headers and libraries in a target specified directory.
install: install-libraries install-headers install-ddk install-directx

-install-libraries: all
- $(mkinstalldirs) $(inst_libdir)
+install-libraries: all $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
for i in $(LIBS); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done

-install-headers:
- $(mkinstalldirs) $(inst_includedir)
+install-headers: $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_includedir)
for i in $(HEADERS); do \
- $(INSTALL_DATA) $(srcdir)/../include/$$i $(inst_includedir)/$$i ; \
+ $(INSTALL_DATA) $(srcdir)/../include/$$i $(DESTDIR)$(inst_includedir)/$$i ; \
done
- $(mkinstalldirs) $(inst_includedir)/GL
+ $(mkinstalldirs) $(DESTDIR)$(inst_includedir)/GL
for i in $(GL_HEADERS); do \
- $(INSTALL_DATA) $(srcdir)/../include/GL/$$i $(inst_includedir)/GL/$$i ; \
+ $(INSTALL_DATA) $(srcdir)/../include/GL/$$i $(DESTDIR)$(inst_includedir)/GL/$$i ; \
done

install-ddk: install-libraries install-headers
@@ -237,17 +249,17 @@ install-directx: install-libraries insta
# uninstall headers and libraries from a target specified directory
uninstall: uninstall-ddk uninstall-directx uninstall-libraries uninstall-headers

-uninstall-libraries:
+uninstall-libraries: $(need-DESTDIR-compatibility)
@for i in $(LIBS); do \
- rm -f $(inst_libdir)/$$i ; \
+ rm -f $(DESTDIR)$(inst_libdir)/$$i ; \
done
- rmdir $(inst_libdir)
+ rmdir $(DESTDIR)$(inst_libdir)

-uninstall-headers:
+uninstall-headers: $(need-DESTDIR-compatibility)
@for i in $(HEADERS); do \
- rm -r $(inst_includedir)/$$i ; \
+ rm -r $(DESTDIR)$(inst_includedir)/$$i ; \
done
- rmdir $(inst_includedir)
+ rmdir $(DESTDIR)$(inst_includedir)

uninstall-ddk:
cd ddk && $(MAKE) -C uninstall $(FLAGS_TO_PASS)
Index: w32api/lib/ddk/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/lib/ddk/Makefile.in,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile.in
--- w32api/lib/ddk/Makefile.in 12 Sep 2006 00:29:04 -0000 1.5
+++ w32api/lib/ddk/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -141,35 +141,47 @@ lib%.a: %.o
$(AR) rc $@ $*.o
$(RANLIB) $@

+need-DESTDIR-compatibility = prefix libdir includedir
+.PHONY: $(need-DESTDIR-compatibility) fail-DESTDIR-compatibility
+
+$(need-DESTDIR-compatibility):
+ @test -z "$(DESTDIR)" || case "$($@)" in ?:*) \
+ $(MAKE) --no-print-directory reject="$@" fail-DESTDIR-compatibility ;; \
+ esac
+
+fail-DESTDIR-compatibility:
+ $(error DESTDIR is not supported when $(reject) contains Win32 path `$($(reject))'; \
+ try `make install $(reject)=$(shell echo '$($(reject))' | sed s,:,:$(DESTDIR),) ...' instead)
+
# install headers and libraries in a target specified directory.
install: install-libraries install-headers

-install-libraries: all
- $(mkinstalldirs) $(inst_libdir)
+install-libraries: all $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
for i in $(LIBS); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done

-install-headers:
- $(mkinstalldirs) $(inst_includedir)
+install-headers: $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_includedir)
for i in $(HEADERS); do \
- $(INSTALL_DATA) $(srcdir)/../../include/ddk/$$i $(inst_includedir)/$$i ; \
+ $(INSTALL_DATA) $(srcdir)/../../include/ddk/$$i $(DESTDIR)$(inst_includedir)/$$i ; \
done

# uninstall headers and libraries from a target specified directory
uninstall: uninstall-libraries uninstall-headers

-uninstall-libraries:
+uninstall-libraries: $(need-DESTDIR-compatibility)
@for i in $(LIBS); do \
- rm -f $(inst_libdir)/$$i ; \
+ rm -f $(DESTDIR)$(inst_libdir)/$$i ; \
done
- rmdir $(inst_libdir)
+ rmdir $(DESTDIR)$(inst_libdir)

-uninstall-headers:
+uninstall-headers: $(need-DESTDIR-compatibility)
@for i in $(HEADERS); do \
- rm -r $(inst_includedir)/$$i ; \
+ rm -r $(DESTDIR)$(inst_includedir)/$$i ; \
done
- rmdir $(inst_includedir)
+ rmdir $(DESTDIR)$(inst_includedir)

dist:
Index: w32api/lib/directx/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/lib/directx/Makefile.in,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile.in
--- w32api/lib/directx/Makefile.in 12 Sep 2006 00:29:04 -0000 1.4
+++ w32api/lib/directx/Makefile.in 29 Oct 2009 18:14:42 -0000
@@ -166,35 +166,47 @@ lib%.a: %.o
$(AR) rc $@ $*.o
$(RANLIB) $@

+need-DESTDIR-compatibility = prefix libdir includedir
+.PHONY: $(need-DESTDIR-compatibility) fail-DESTDIR-compatibility
+
+$(need-DESTDIR-compatibility):
+ @test -z "$(DESTDIR)" || case "$($@)" in ?:*) \
+ $(MAKE) --no-print-directory reject="$@" fail-DESTDIR-compatibility ;; \
+ esac
+
+fail-DESTDIR-compatibility:
+ $(error DESTDIR is not supported when $(reject) contains Win32 path `$($(reject))'; \
+ try `make install $(reject)=$(shell echo '$($(reject))' | sed s,:,:$(DESTDIR),) ...' instead)
+
# install headers and libraries in a target specified directory.
install: install-libraries install-headers

-install-libraries: all
- $(mkinstalldirs) $(inst_libdir)
+install-libraries: all $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
for i in $(LIBS); do \
- $(INSTALL_DATA) $$i $(inst_libdir)/$$i ; \
+ $(INSTALL_DATA) $$i $(DESTDIR)$(inst_libdir)/$$i ; \
done

-install-headers:
- $(mkinstalldirs) $(inst_includedir)
+install-headers: $(need-DESTDIR-compatibility)
+ $(mkinstalldirs) $(DESTDIR)$(inst_includedir)
for i in $(HEADERS); do \
- $(INSTALL_DATA) $(srcdir)/../../include/directx/$$i $(inst_includedir)/$$i ; \
+ $(INSTALL_DATA) $(srcdir)/../../include/directx/$$i $(DESTDIR)$(inst_includedir)/$$i ; \
done

# uninstall headers and libraries from a target specified directory
uninstall: uninstall-libraries uninstall-headers

-uninstall-libraries:
+uninstall-libraries: $(need-DESTDIR-compatibility)
@for i in $(LIBS); do \
- rm -f $(inst_libdir)/$$i ; \
+ rm -f $(DESTDIR)$(inst_libdir)/$$i ; \
done
- rmdir $(inst_libdir)
+ rmdir $(DESTDIR)$(inst_libdir)

-uninstall-headers:
+uninstall-headers: $(need-DESTDIR-compatibility)
@for i in $(HEADERS); do \
- rm -r $(inst_includedir)/$$i ; \
+ rm -r $(DESTDIR)$(inst_includedir)/$$i ; \
done
- rmdir $(inst_includedir)
+ rmdir $(DESTDIR)$(inst_includedir)

dist:

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

mingw-destdir.patch7a.gz (2K) Download Attachment

Re: Honor DESTDIR in w32api and mingw

2009-10-29T14:10:36Z

On Wednesday 28 October 2009 22:09:12 Charles Wilson wrote:
> > We're assuming GNU Make here, right? (There's a comment saying
> > that it is a necessary requirement, and we freely use features
> > which make it so). Any macros defined on the command line, as
> > DESTDIR *must* be, should be passed automatically to the
> > recursive sub-make,
>
> I didn't know that.

Quoting from the official `GNU Make' Texinfo manual:

$ info make Variables/Recursion
...
The special variable `MAKEFLAGS' is always exported [*]
(unless you unexport it). ...

`make' automatically passes down variable values that were
defined on the command line, by putting them in the `MAKEFLAGS'
variable. *Note Options/Recursion::.
...

[*] In this context, `exported' and `passed down' are synonymous.

> So...Ok, with that change (removing DESTDIR="${DESTDIR)"
> throughout)?

Yes; (I guess you don't need it in `FLAGS_TO_PASS' either, since it's
already implicit in `MAKEFLAGS'). Please feel free to commit, when
you are ready.

--

Regards,
Keith.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr