Re: [Mingw-users] Necessary environment path settings?

[keithmarshall]

Summarising the follow-up discussion, and taking the opportunity to add
my own two pennyworth:--

On Sunday 23 March 2008 12:45, Roland Schwarz wrote:
> With the mingw 3.4.5 release it was possible to invoke
> the compiler just by calling with an absolute path without
> the need to set up the path variable before.
>
> This is not true anymore for 4.2.1. I get a CreateProcess:
> No such file or directory error message instead.
> Has this been changed intentionally?

No.  Assuming that you are using one of our pre-built binary packages
for binutils-2.18.50, the follow-up discussion suggests that this is an
inadvertent packaging bug; thanks for alerting us.

On Sunday 23 March 2008 16:47, John E. / TDM wrote:

> Looking at the output of `path-to-mingw\gcc.exe -print-search-dirs`,
> it should be fairly obvious what's happening. For the programs search
> directories, there is no path corresponding to the root "bin"
> directory, which is where your binutils executables live. There is,
> however, a path corresponding to "path-to-mingw\mingw32\bin", which
> is an alternate location for the binutils tools. For a workaround,
> you can try copying the binutils executables there. (Depending on
> which binutils release you have, there may already be some empty
> files there -- I have seen this packaging bug with the 2.18.50
> release.)

On Monday 24 March 2008 01:07, Danny Smith wrote:
> [path-to-mingw\mingw32\bin] is not the alternate location.  This is
> the first place the compuiler looks. That is where binutils package is
> supposed to install them.

On Monday 24 March 2008 02:48, John E. / TDM wrote:
> That's good to know.  Does this indicate a packaging bug in the
> binutils 2.18.50 tech preview, since they were built with a different
> target triplet (i686-pc-mingw32)?

Yes.  I do not want to point any "finger of blame", for witch hunts
serve no useful purpose.  The underlying cause of the problem lies in
the complete absence of any agreed and formally documented policy on
how the MinGW packages should be prepared for release; for that, the
project team, as a whole, is collectively responsible.

> If not, I think it should at least merit a warning to the effect
> of "since this build uses a newer target triplet, you have to have the
> bin directory in your PATH".

It *is* a packaging bug.  For those afflicted by it, this is a possible
workaround, although perhaps not the most effective one.

On Monday 24 March 2008 12:12, JonY wrote:
> I noticed that some packages using autotools which would fail when
> the mingw provided gcc 3.4.5 which was targeted at mingw32 and a
> newer user built binutils which was targeted at i686-pc-mingw32 was
> used. It was looking for the ld linker in the wrong place.

As Danny pointed out, the correct installation path, as *he* specified
it for his MinGW-GCC builds is /path/to/mingw/mingw32/{bin,lib}; if we
accept that as the standard, (and it seems reasonable, and as good as
any to me), then...

> The newer binutils executables would reside in /mingw/bin and
> /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32
> containing the older binutils was removed.

the implicit `i686-pc-mingw32' target specification used when building
the binutils-1.18.50 binary package is only the apparent cause of the
packaging bug; the real underlying cause is lack of an appropriately
documented packaging methodology.

The reason this didn't show up, until you removed the older binutils
from /path/to/mingw/mingw32/{bin,lib} was that GCC was actually *using*
these older tools; you may have thought you had installed the newer
binutils, but you were never using it.

> Problem fixed by using junction points to link mingw32 and
> i686-pc-mingw32 together.

This is another possible workaround, but I wouldn't classify it as
a "fix"; the only ultimately acceptable "fix" is to rebuild the binary
package, with the appropriately agreed target specification, repackage
and replace the defective binary release tarballs on the SF download
site, and mirrors.

For those afflicted by this bug, a further possible workaround would be
to physically *move* everything from /path/to/i686-pc-mingw32/{bin,lib}
into the corresponding /path/to/mingw/mingw32/{bin,lib} trees, in place
of any similarly named component files which are already there; of the
three workarounds suggested, this would be my preferred choice, as I
would expect it to restore everything to the state it should be in, to
conform with Danny's previous de-facto build standard.

On Monday 24 March 2008 11:51, Earnie Boyd wrote:
> I thought the target was supposed to be stated without the triplet,
> meaning --target=mingw32, for the distributed binaries since i686-pc
> has little relevance to MinGW.

I agree that `i686-pc', (as such, or with any other CPU designation),
has little relevance for MinGW; formalising the de-facto use of just
`mingw32' here makes sense to me.

It does seem somehow anomalous to be required to specify *any* form of
`--target=target_alias', for self-hosted (native) builds, or even of
crossed-native builds, of any package; indeed, it would be unnecessary
for building of the entire tool chain as a single integrated package.  
In the particular case of MinGW, however, it *is* necessary, to allow
for mixing and matching of component packages at different release
points, and from different maintainers.  This particular problem has
arisen because the binutils-2.18.50 tech preview has been built with no
`--target=target_alias' specified, on an i686 host, so target_alias has
been implicitly determined, by running config.guess, and the resultant
`i686-pc-mingw32' does not conform to the de-facto mingw32 standard.

There is a lesson to be learnt here; let's not ignore it.  We should
take this discussion to the developers' list, where we formally agree,
and document, a standard procedure for building MinGW packages for
public release, so that future maintainers can understand the reasons
for, and continue to follow, the standards in use today.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting Keith Marshall <keithmarshall@...>:

>
> There is a lesson to be learnt here; let's not ignore it.  We should
> take this discussion to the developers' list, where we formally agree,
> and document, a standard procedure for building MinGW packages for
> public release, so that future maintainers can understand the reasons
> for, and continue to follow, the standards in use today.
>

We should carry it further and add a documented section for this in the
wiki.  Somewhere in the bowels of ancient mingw-dvlpr threads there
should be a discussion on this with an agreement to use --prefix=/mingw
--host=mingw32 for all distributed binary packages.  I tried looking
for the thread before responding and gave up after about five minutes.  
I did find examples[1] from Danny of his configure statement for an
2.95.3 version of GCC.

[1]
http://sourceforge.net/mailarchive/message.php?msg_id=20010516025237.22456.qmail%40web6402.mail.yahoo.com

Earnie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Tuesday 25 March 2008 19:32, Earnie Boyd wrote:

> Quoting Keith Marshall <keithmarshall@...>:
> > There is a lesson to be learnt here; let's not ignore it.  We
> > should take this discussion to the developers' list, where we
> > formally agree, and document, a standard procedure for building
> > MinGW packages for public release, so that future maintainers can
> > understand the reasons for, and continue to follow, the standards
> > in use today.
>
> We should carry it further and add a documented section for this in
> the wiki.

That's what I had in mind; first discuss and agree the requirements
here, then document and publish on the wiki or web site.

> Somewhere in the bowels of ancient mingw-dvlpr threads
> there should be a discussion on this with an agreement to use
> --prefix=/mingw --host=mingw32 for all distributed binary packages.
> I tried looking for the thread before responding and gave up after
> about five minutes. I did find examples[1] from Danny of his
> configure statement for an 2.95.3 version of GCC.

Danny has always provided his build script, AFAICT.  However, IMHO that
alone isn't sufficient; it shows the `how', but it doesn't explain the
`why'.  Without that extra detail, a future maintainer could easily, as
I did, assume that --target=mingw32 is redundant -- for a self-hosted
build it normally would be -- whereas in this case it is essential.

OTOH, --host=mingw32 should not be necessary for a self-hosted build,
and indeed, for a crossed-native build such as I do, it would more than
likely be just plain wrong.

These more recent references show how I built binutils, for the purpose
of regenerating the source tarball in fully `distributable' condition:
http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678
http://article.gmane.org/gmane.comp.gnu.mingw.user/25029

For this purpose, it was good enough, but it isn't quite correct for
generating a binary distribution.  Nonetheless, with a few minor, but
critical corrections, it could form the basis for developing a formally
standardised procedure for building binutils.  Augment that with the
corresponding info relating to GCC, mingw-runtime and w32api, and we're
well on the way.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

Apologies all, I've been really busy at work so I haven't been
following the lists as closely as I normally do.

>  These more recent references show how I built binutils, for the purpose
>  of regenerating the source tarball in fully `distributable' condition:
>  http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678
>  http://article.gmane.org/gmane.comp.gnu.mingw.user/25029

I've followed Keith's examples and generated a new binutils
distribution with the following options:

$ ../binutils-2.18.50/configure --prefix=/mingw/ --build=mingw32
--host=mingw32 --target=mingw32 --with-gcc --with-gnu-as --with-gnu-ld
--disable-nls
$ make CFLAGS="-s -O2 -mms-bitfields -mtune=i686"
$ make prefix=`cd ../dist;pwd` install

The build is available here:

http://emergedesktop.org/mingw/binutils-2.18.50-20080109-2.tar.gz

Keith, perhaps you can take a quick look, once I get the OK I'll
upload it to SF and post an announcement.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[NightStrike]

On 3/25/08, Keith Marshall <keithmarshall@...> wrote:
> > The newer binutils executables would reside in /mingw/bin and
> > /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32
> > containing the older binutils was removed.
>
> the implicit `i686-pc-mingw32' target specification used when building
> the binutils-1.18.50 binary package is only the apparent cause of the
> packaging bug; the real underlying cause is lack of an appropriately
> documented packaging methodology.

> > Problem fixed by using junction points to link mingw32 and
> > i686-pc-mingw32 together.
>
> This is another possible workaround, but I wouldn't classify it as
> a "fix"; the only ultimately acceptable "fix" is to rebuild the binary
> package, with the appropriately agreed target specification, repackage
> and replace the defective binary release tarballs on the SF download
> site, and mirrors.
> On Monday 24 March 2008 11:51, Earnie Boyd wrote:
> > I thought the target was supposed to be stated without the triplet,
> > meaning --target=mingw32, for the distributed binaries since i686-pc
> > has little relevance to MinGW.
>
> I agree that `i686-pc', (as such, or with any other CPU designation),
> has little relevance for MinGW; formalising the de-facto use of just
> `mingw32' here makes sense to me.

If you want to be able to have x86_64 support merge back in to mingw,
then supporting the CPU designation is advantageous.

To that end, supporting the gnu standard canonicalization fully is
advantageous.  With the way I build things, I can have both
i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the
same root directory structure.  However, the requirement of the lone
"mingw32" directory makes that difficult.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting NightStrike <nightstrike@...>:


>>
>> I agree that `i686-pc', (as such, or with any other CPU designation),
>> has little relevance for MinGW; formalising the de-facto use of just
>> `mingw32' here makes sense to me.
>
> If you want to be able to have x86_64 support merge back in to mingw,
> then supporting the CPU designation is advantageous.
>

The host/target becomes mingw64 is all.

> To that end, supporting the gnu standard canonicalization fully is
> advantageous.  With the way I build things, I can have both
> i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the
> same root directory structure.  However, the requirement of the lone
> "mingw32" directory makes that difficult.
>

So you can with --host=mingw32 and --host=mingw64 as well.  The triplet
is really confusing, especially when i686 has no real value.

Earnie

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[NightStrike]

On 3/26/08, Earnie Boyd <earnie@...> wrote:

>
> Quoting NightStrike <nightstrike@...>:
>
>
> >>
> >> I agree that `i686-pc', (as such, or with any other CPU designation),
> >> has little relevance for MinGW; formalising the de-facto use of just
> >> `mingw32' here makes sense to me.
> >
> > If you want to be able to have x86_64 support merge back in to mingw,
> > then supporting the CPU designation is advantageous.
> >
>
> The host/target becomes mingw64 is all.

There are many many discussions over mingw64 NOT meaning 64-bit
windows.  For this reason (and others), the trailing number has been
removed from mingw for canonicalized triplets.  As a point of fact,
the triplet for Win64 is x86_64-pc-mingw32, and will eventually become
just x86_64-pc-mingw.

> > To that end, supporting the gnu standard canonicalization fully is
> > advantageous.  With the way I build things, I can have both
> > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the
> > same root directory structure.  However, the requirement of the lone
> > "mingw32" directory makes that difficult.
> >
>
> So you can with --host=mingw32 and --host=mingw64 as well.  The triplet
> is really confusing, especially when i686 has no real value.

I have 3 questions on this -- (1) Why do you and others keep saying
that the cpu choice has no real value?  (2) Why is the triplet
confusing?  (3) Why does mingw break the paradigms set up by every
other gcc target?

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

I've uploaded the tarball again, for some reason the original archive
had 0 byte binaries in the mingw32/bin directory:

http://emergedesktop.org/mingw/binutils-2.18.50-20080109-2.tar.gz

Chris

--
Chris Sutcliffe
http://emergedesktop.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting NightStrike <nightstrike@...>:

> On 3/26/08, Earnie Boyd <earnie@...> wrote:
>>
>> Quoting NightStrike <nightstrike@...>:
>>
>>
>> >>
>> >> I agree that `i686-pc', (as such, or with any other CPU designation),
>> >> has little relevance for MinGW; formalising the de-facto use of just
>> >> `mingw32' here makes sense to me.
>> >
>> > If you want to be able to have x86_64 support merge back in to mingw,
>> > then supporting the CPU designation is advantageous.
>> >
>>
>> The host/target becomes mingw64 is all.
>
> There are many many discussions over mingw64 NOT meaning 64-bit
> windows.  For this reason (and others), the trailing number has been
> removed from mingw for canonicalized triplets.  As a point of fact,
> the triplet for Win64 is x86_64-pc-mingw32, and will eventually become
> just x86_64-pc-mingw.
>

And who the hell made that decision without appropriate discussion
here?  x86_64-pc-mingw32 of course is meaningless.  x86_64-pc-mingw64
is what it should be.

>> > To that end, supporting the gnu standard canonicalization fully is
>> > advantageous.  With the way I build things, I can have both
>> > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the
>> > same root directory structure.  However, the requirement of the lone
>> > "mingw32" directory makes that difficult.
>> >
>>
>> So you can with --host=mingw32 and --host=mingw64 as well.  The triplet
>> is really confusing, especially when i686 has no real value.
>
> I have 3 questions on this -- (1) Why do you and others keep saying
> that the cpu choice has no real value?  (2) Why is the triplet
> confusing?  (3) Why does mingw break the paradigms set up by every
> other gcc target?
>

Because it only reflects the build system since the target is i386 with
tunings toward i686.  Since i686 isn't really targeted then it is
therefore meaningless.  MinGW doesn't break any paradigm, it chooses to
allow those using less than i686 to use its distributions without the
need to be specific for any one CPU model.  x86_64-pc-mingw64 is
correct because x286_64 will happen just as i186, i286, i386, i486, etc
did.

Earnie

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[NightStrike]

On 3/26/08, Earnie Boyd <earnie@...> wrote:

> Quoting NightStrike <nightstrike@...>:
> > On 3/26/08, Earnie Boyd <earnie@...> wrote:
> >> Quoting NightStrike <nightstrike@...>:
> >> >>
> >> >> I agree that `i686-pc', (as such, or with any other CPU designation),
> >> >> has little relevance for MinGW; formalising the de-facto use of just
> >> >> `mingw32' here makes sense to me.
> >> >
> >> > If you want to be able to have x86_64 support merge back in to mingw,
> >> > then supporting the CPU designation is advantageous.
> >> >
> >>
> >> The host/target becomes mingw64 is all.
> >
> > There are many many discussions over mingw64 NOT meaning 64-bit
> > windows.  For this reason (and others), the trailing number has been
> > removed from mingw for canonicalized triplets.  As a point of fact,
> > the triplet for Win64 is x86_64-pc-mingw32, and will eventually become
> > just x86_64-pc-mingw.
> >
>
> And who the hell made that decision without appropriate discussion
> here?  x86_64-pc-mingw32 of course is meaningless.  x86_64-pc-mingw64
> is what it should be.

First, your constant aggressive tone is neither warranted nor
appreciated.  Please behave civilly.

As to your question, it was Ben Elliston and Nick Clifton, as I
recall. You can check the mailing lists and the changes to
config.guess.  There's also a post from Brian Dessent, as I recall
(though it was over a year ago and wasn't one of the many posts by
Brian that I saved), that explains why the 32 in mingw32 shouldn't
specify the bit-width of the cpu.  I believe he also mentioned in
there that i686-pc-mingw32 is an appropriate target name.

Kai was originally making patches that targetted x86_64-pc-mingw64,
but all that stopped once there was reached consensus between binutils
and gcc.  If you were not part of that discussion, then maybe you'd
like to raise it with the people that drove the change.  Talking on
this list about issues in binutils and gcc won't involve the right
people.

> >> > To that end, supporting the gnu standard canonicalization fully is
> >> > advantageous.  With the way I build things, I can have both
> >> > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the
> >> > same root directory structure.  However, the requirement of the lone
> >> > "mingw32" directory makes that difficult.
> >> >
> >>
> >> So you can with --host=mingw32 and --host=mingw64 as well.  The triplet
> >> is really confusing, especially when i686 has no real value.
> >
> > I have 3 questions on this -- (1) Why do you and others keep saying
> > that the cpu choice has no real value?  (2) Why is the triplet
> > confusing?  (3) Why does mingw break the paradigms set up by every
> > other gcc target?
> >
>
> Because it only reflects the build system since the target is i386 with
> tunings toward i686.  Since i686 isn't really targeted then it is
> therefore meaningless.  MinGW doesn't break any paradigm, it chooses to
> allow those using less than i686 to use its distributions without the
> need to be specific for any one CPU model.  x86_64-pc-mingw64 is
> correct because x286_64 will happen just as i186, i286, i386, i486, etc
> did.

The paradigm is that target-specific binaries and libraries should in
in subdirectories of the target triplet directory.  So for instance,
i386-pc-mingw32/bin holds gcc.exe, whereas /bin holds
i386-pc-mingw32-gcc.exe, or the default gcc.exe for the system (that
is, if you are building for i386 instead of some other target, like
i686).  This makes it easy to have multiply-targetted compilers
installed in the same root structure.

In actuality, gcc currently is hard coded to look in /mingw/lib for
libraries during a build of a cross compiler, which causes collisions
now that there are multiple possible targets for mingw platforms.
That's easy to work around, but it could be handled more elegantly.


I really don't understand why you would not want to make it clear what
CPU you are targetting (i386, i686, x86_64, etc.), and if you are
willing to explain it in a calm manner, I'm willing to listen.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Wednesday 26 March 2008 01:56, Chris Sutcliffe wrote:
> I've followed Keith's examples and generated a new binutils
> distribution with the following options:
>
> $ ../binutils-2.18.50/configure --prefix=/mingw/ --build=mingw32
> --host=mingw32 --target=mingw32 --with-gcc --with-gnu-as
> --with-gnu-ld --disable-nls
> $ make CFLAGS="-s -O2 -mms-bitfields -mtune=i686"
> $ make prefix=`cd ../dist;pwd` install

You missed this step:
|   $ find . -type f -iname dir -exec rm -i {} +
|
| Note [the second of] the two find commands.  The first cleans up the
| source tree, if the original tarball was created for an original
| source tree checked out from CVS, (as was the case for Danny's 2.17.50
| release); the second expunges any info `dir' files, which should
| *never* be included in any binary distribution package;

> The build is available here:
>
> http://emergedesktop.org/mingw/binutils-2.18.50-20080109-2.tar.gz
>
> Keith, perhaps you can take a quick look, once I get the OK I'll
> upload it to SF and post an announcement.

> I've uploaded the tarball again, for some reason the original archive
> had 0 byte binaries in the mingw32/bin directory:

It looks superficially ok, but you do need to repackage your dist tree
once more, *after* you've removed that offending `info/dir' file; that
will break the existing info database of any user who cares.

Regards,
Keith.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Wednesday 26 March 2008 18:40, NightStrike wrote:

> > > There are many many discussions over mingw64 NOT meaning 64-bit
> > > windows.  For this reason (and others), the trailing number has
> > > been removed from mingw for canonicalized triplets.  As a point
> > > of fact, the triplet for Win64 is x86_64-pc-mingw32, and will
> > > eventually become just x86_64-pc-mingw.
> >
> > And who the hell made that decision without appropriate discussion
> > here?  x86_64-pc-mingw32 of course is meaningless.
> >  x86_64-pc-mingw64 is what it should be.
>
> First, your constant aggressive tone is neither warranted nor
> appreciated.  Please behave civilly.

Well, Earnie may have adopted an aggressive tone, but I can readily
understand the frustration that has led to it.

> As to your question, it was Ben Elliston and Nick Clifton, as I
> recall.

Ben Elliston and Nick Clifton have no business pushing this decision
through, without the courtesy of even a mention to those who officially
maintain MinGW.  You also mentioned Brian Dessent, who, while he is a
frequent contributor to discussion on MinGW lists, has no official
standing with the project, and isn't authorised in any way to speak on
our behalf.

So, to return to your question, what on earth could mingw64 possibly
mean, if not MinGW for a 64-bit platform.  The canonical form of a host
triplet is CPU-VENDOR-OSTYPE.  If the OSTYPE is mingw32, that is
unambiguously MinGW for any one of the i[34567]86 processor family, so
the CPU and VENDOR fields are completely redundant; indeed, what VENDOR
does `pc' signify anyway?  IBM?  Sun?  Fred Bloggs?  It is completely
meaningless, and might as well be discarded; the equally acceptable
i386-unknown-mingw32 is preferable, IMO.

Right.  VENDOR is redundant.  It conveys no useful information, when the
only platform targetted by the OSTYPE is singularly identified, as it
is in the case of OSTYPE == mingw32, (which targets i[34567]86 generic
family processors *exclusively*).  By the same token, CPU is redundant
too, because it is unambiguously identified when OSTYPE == mingw32,
just as OSTYPE == mingw64 would be singularly unambiguous; in either
case config.sub can unambiguously canonicalise the target, *solely* on
either one of these OSTYPEs:

  OSTYPE == mingw32  ==>  i386-unknown-mingw32
  OSTYPE == mingw64  ==>  x86_64-unknown-mingw64

so why burden us with redundant information?  We may just as well
dispense with the CPU and VENDOR fields, and still have the appropriate
tool chain unambiguously specified by just the OSTYPE name.

> > >> > To that end, supporting the gnu standard canonicalization
> > >> > fully is advantageous.  With the way I build things, I can
> > >> > have both i686-pc-mingw and x86_64-pc-mingw targetted
> > >> > compilers installed in the same root directory structure.
> > >> >  However, the requirement of the lone "mingw32" directory
> > >> > makes that difficult.

I don't see why.  The name of a tool chain does not *need* to be
identified by a fully qualified canonical triplet; as long as each
independent tool chain has a unique prefix, any number can live quite
happily together -- indeed, as of today, I have a `mingw32' tool chain
and my original `i586-mingw32' chain, co-existing in complete harmony,
(and I have never included the meaningless VENDOR = pc component).

> > > I have 3 questions on this -- (1) Why do you and others keep
> > > saying that the cpu choice has no real value?

Simply because it is already implicit in the OSTYPE == mingw32; why do
you need the tautology of saying i386 twice?  (Do notice that publicly
distributed MinGW binaries target generic i[34567]86, so it is quite
pointless to declare it to be any *specific* member of the family).

> > > (2) Why is the triplet confusing?

Which member of the i[34567]86 family is appropriate?  To specify any
particular one, other than perhaps basic i386, would be *wrong*.

> > > (3) Why does mingw break the paradigms set up by every other gcc
> > > target?

Other targets may need the full triplet; `linux' on its own would be
horrendously ambiguous, because it supports so many *different* CPU
architectures.  Some CPU types exhibit different characteristics, when
sourced from different vendors.  For tools targetting such platforms,
the additional information is necessary to avoid ambiguity.  mingw32
and mingw64 are completely unambiguous, so there is no need for the
redundancy in specifying the tool chain prefix.

> The paradigm is that target-specific binaries and libraries should in
> in subdirectories of the target triplet directory.  So for instance,
> i386-pc-mingw32/bin holds gcc.exe, whereas /bin holds
> i386-pc-mingw32-gcc.exe,

The same holds identically true for ${prefix}/bin/mingw32-gcc.exe and
${prefix}/mingw32/bin/gcc.exe; the additional i386-pc- prefix is
redundant and unnecessary.

> or the default gcc.exe for the system (that
> is, if you are building for i386 instead of some other target, like
> i686).

There is no point in discriminating between i386-mingw32 and
i686-mingw32; these would be the same tool chain.

> This makes it easy to have multiply-targetted compilers
> installed in the same root structure.

And it is equally straightforward with the abbreviated prefix; the only
requirement is that the individual tool chains have *unique* prefixes;
they do *not* need to be named with the full canonical triplet.

Regards,
Keith.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Wednesday 26 March 2008 15:17, Chris Sutcliffe wrote:
> I've uploaded the tarball again, for some reason the original archive
> had 0 byte binaries in the mingw32/bin directory:

I didn't notice this, when I checked out your original archive.  I'd
downloaded it, and installed it into a sandboxed clone of my regular
MinGW installation, and everything worked perfectly.

Inspection of the original archive with `tar ztvf ...' reveals the
explanation: the executables in mingw32 are indeed shown as zero size,
but they are also recorded as links to their counterparts in bin, which
are the actual executable images in the tarball, and so non-zero size.

When this archive is unpacked with MSYS tar, on NTFS the links are
re-established, (`ls -l' shows link counts of two), and it all `Just
Works(TM)'.  On FAT32, where file-to-file hard links are not supported,
MSYS tar will still DTRT, and resolve those links by creating copies of
the respective files, so again, everything will `Just Work(TM)'.

So, all well and good for you and me; we will use MSYS tar to install
MinGW packages, but Joe User is just as likely to use WinZip, or 7-Zip,
or some other archiving tool of his choice.  I just checked it with
WinZip-9.0, and that doesn't recognise that the 'mingw32/bin' even
exists in the archive!  Thus, it simply isn't acceptable for us to
distribute archives which rely on the archiving tool to to reinstate
file-to-file links, which have been recorded on archive creation, if we
wish to support users of such naive Win32 archiving tools, rather than
require every user to adopt MSYS.

In my sample build procedure, I suggested using:

  $ tar czhf $RELEASE_DIR/binutils-2.18.50-20071123-bin.tar.gz *

as the command to create the binary release tarball, (obviously with the
version number and snapshot serialisation adjusted as appropriate).  Do
please note the `h' flag, amongst the `czhf'; it is this which ensures
that all necessary files are *copied* to the archive, rather than
linked, as they would be if this flag is omitted.  To ensure integrity
of our release tarballs, I would suggest that this `h' flag should be
mandatory, when creating the archives.

The above sample command also raises two other potential discussion
points: first note that I've used `z' --> `.tar.gz' as the compression
standard, and second that I've included a `-bin' qualifier for the
archive name.

Some might argue for `j' --> `.tar.bz2' for the compression standard,
since it generally, (but not always), results in smaller archives, and
we've certainly used that for some of our releases, particularly for
the MSYS packages.  While it may be fair to assume that MSYS users will
install MSYS packages using MSYS' own tar command, so they can readily
handle this format, I don't think it should be adopted for the more
general case of MinGW packages.  Yes, I know there are better archive
tools for Win32 than WinZip, but AFAIK it is still widely used, and it
does not support bzipped archives, but it does support `.tar.gz'.  If
we adopt `.tar.bz2' format, then we will alienate potential users who
do not wish to use MSYS, and who do want to use WinZip; not good.

On the subject of the `-bin' qualifier, my mind is less firmly made up.  
In the past, we have more often released binary packages without such a
qualifier, than we have with, although there are examples to be found.  
My own opinion leans toward including it, at least for future binary
releases in `.tar.gz', (or in `.tar.bz2'), or in `.zip' format, as it
does help to emphasise that the package is indeed a binary release;
OTOH, for those packages released in self extracting `.exe' format, I
suspect that such a qualifier would be redundant, (unless we were to
start releasing source archives in such format, which I do not think we
should ever do).  However, this is a level of detail, on which I will
willingly accede to majority preference.

Any comments?

Regards,
Keith.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

I'm about to upload some GCC 'tech previews' within the next few days so
this discussion is timely.  See below.


Keith Marshall wrote:

> In my sample build procedure, I suggested using:

Where is this 'sample build procedure'?

> To ensure integrity
> of our release tarballs, I would suggest that this `h' flag should be
> mandatory, when creating the archives.

I agree.  I think it is premature to use links in MinGW packages, as as
the benefit is minimal, archiver support is poor, hard links are
surprising to many Windows uses (and many Windows programs), and most
installations still do not support file soft links.

> The above sample command also raises two other potential discussion
> points: first note that I've used `z' --> `.tar.gz' as the compression
> standard

I agree.  .tar.gz is a file format that has substantial support and all
of the capabilities that MinGW needs.  Chasing the latest compression
fad, whether its bzip2, lzma, rzip, or 7zip is probably not productive
when the marginal gains do not offset the increased difficulty of
decompression.

Universality is the primary goal; compression ratio is secondary.

> and second that I've included a `-bin' qualifier for the
> archive name.

So source releases will still have -src?  If so, -bin may not add anything.

I don't care either way, but the more qualifiers that are added, the
more difficult it may be for users to figure out which packages they need.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Thursday 27 March 2008 21:13, Aaron W. LaFramboise wrote:
> > In my sample build procedure, I suggested using:
>
> Where is this 'sample build procedure'?

It is in the reference I provided earlier in the thread -- it was
specific to binutils, and framed for cross compiling:
http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678

so would need adaptation for self hosted builds, and for GCC, etc.  I
offered it primarily as a basis for further discussion.

> > and second that I've included a `-bin' qualifier for the
> > archive name.
>
> So source releases will still have -src?

Yes.

> If so, -bin may not add anything.

It may not add anything, but IMO it removes potential ambiguity.  It is
easier to direct someone to look for a `-bin' package, than to look for
one with no qualifier, when they want a binary package.

> I don't care either way,

I don't feel strongly enough about it to insist upon it, but I thought
it worthy of consideration.

> but the more qualifiers that are added, the
> more difficult it may be for users to figure out which packages they
> need.

We should specify a minimal, well defined set.  I suggest:

  -src      source package, as at present.

  -bin      binary package, i.e. pre-built executable programs, and
            any supporting DLLs they may require; this should, in
            general, be a fully self-contained package.

  -dev      (or maybe -devel), a package providing precompiled static
            libraries, import libraries and associated header files,
            for optional extra feature support, (i.e. additional to
            the standard system libs and headers, which would remain
            integral to the GCC and binutils `-bin' packages).

  -dll      stand alone DLLs associated with `-dev' packages, when
            there is no `-bin' package with which these would be
            logically associated.

Regards,
Keith.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

Hey Keith,

>  So, all well and good for you and me; we will use MSYS tar to install
>  MinGW packages, but Joe User is just as likely to use WinZip, or 7-Zip,
>  or some other archiving tool of his choice.  I just checked it with
>  WinZip-9.0, and that doesn't recognise that the 'mingw32/bin' even
>  exists in the archive!  Thus, it simply isn't acceptable for us to
>  distribute archives which rely on the archiving tool to to reinstate
>  file-to-file links, which have been recorded on archive creation, if we
>  wish to support users of such naive Win32 archiving tools, rather than
>  require every user to adopt MSYS.

FWIW, 7-zip doesn't resolve the links either, so they are 0 size files
when extracted.

>  In my sample build procedure, I suggested using:
>
>   $ tar czhf $RELEASE_DIR/binutils-2.18.50-20071123-bin.tar.gz *
>
>  as the command to create the binary release tarball, (obviously with the
>  version number and snapshot serialisation adjusted as appropriate).  Do
>  please note the `h' flag, amongst the `czhf'; it is this which ensures
>  that all necessary files are *copied* to the archive, rather than
>  linked, as they would be if this flag is omitted.  To ensure integrity
>  of our release tarballs, I would suggest that this `h' flag should be
>  mandatory, when creating the archives.

I tried this (using the 'h' option), unfortunately it didn't help.  Is
this a possible issue with MSYS tar?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

>  We should specify a minimal, well defined set.  I suggest:
>
>   -src      source package, as at present.
>
>   -bin      binary package, i.e. pre-built executable programs, and
>             any supporting DLLs they may require; this should, in
>             general, be a fully self-contained package.
>
>   -dev      (or maybe -devel), a package providing precompiled static
>             libraries, import libraries and associated header files,
>             for optional extra feature support, (i.e. additional to
>             the standard system libs and headers, which would remain
>             integral to the GCC and binutils `-bin' packages).
>
>   -dll      stand alone DLLs associated with `-dev' packages, when
>             there is no `-bin' package with which these would be
>             logically associated.

Seems reasonable.  I'll adopt this going forward with the packages I
maintain.  I assume that mingw-runtime and w32api would contain only
-src and -dev packages (i.e. no -bin) given the above definitions?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Chris Sutcliffe wrote:

> Seems reasonable.  I'll adopt this going forward with the packages I
> maintain.  I assume that mingw-runtime and w32api would contain only
> -src and -dev packages (i.e. no -bin) given the above definitions?

Working on a longer reply, but doesn't mingw-runtime provide
mingwm10.dll? That should go in a -dll package, IMO.

More formally,
   mingw-runtime-3.14-1-src.tar.gz
   mingw-runtime-3.14-1-dev.tar.gz
   mingw-runtime-3.14-1-dll0.tar.gz
(Note the '0')

--
Chuck


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Gee, I wish this discussion had reached this point BEFORE I updated all
those MSYS Supplemental packages...

Keith Marshall wrote:

> We should specify a minimal, well defined set.  I suggest:
>
>   -src      source package, as at present.
>
>   -bin      binary package, i.e. pre-built executable programs, and
>             any supporting DLLs they may require; this should, in
>             general, be a fully self-contained package.
>
>   -dev      (or maybe -devel), a package providing precompiled static
>             libraries, import libraries and associated header files,
>             for optional extra feature support, (i.e. additional to
>             the standard system libs and headers, which would remain
>             integral to the GCC and binutils `-bin' packages).
>
>   -dll      stand alone DLLs associated with `-dev' packages, when
>             there is no `-bin' package with which these would be
>             logically associated.

This proposal works for me. However, I'd suggest *routinely* splitting
DLLs into a -dll package, separate from the -bin, even when a -bin
package could contain the DLLs and other executables.

I'm not SURE that it is general enough to solve ALL the possible
packaging issues that may arise -- especially if MSYS/MinGW adopts a
more formal package/dependency management system (like rpm [horror!] or
even a fork of cygwin's setup).  But, that may be borrowing trouble we
don't need to worry about just yet -- because frankly, there aren't a
whole lot of "pre-compiled" packages for "mingw" being generated outside
of binutils and gcc itself (that's what mingwPORTs are for).  So really,
this whole issue might only affect MSYS packages.  And those aren't
exactly hotbeds of activity...


But, just to outline the possible issues...(don't worry, at the end I
come back around to endorsing Keith's proposal above, with the 'make a
-dllN package whenever possible' proviso...)


Take libintl, for instance. Gettext provides libintl, plus a number of
utilities.  Because it is an autotool, I provided a precompiled "native"
(e.g. mingw-targeted, not msys-targeted) port -- as well as an
msys-targeted version.

Bruno Haible, the upstream maintainer of gettext, actually recommends a
specific breakdown between "normal" utilities (in a 'gettext-runtime'
package or similar) and "development" utilities (in a 'gettext-devel'
package or similar).

However, the libintl DLL (e.g. cygintl-8.dll on cygwin, libintl-8.dll on
mingw, msys-intl-8.dll on msys) might be "depended on" by any number of
other packages.  Maybe even mingw-gcc-4.x.x might depend dynamically on
the mingw libintl-8.dll (or the mingw libgmp-X.dll, libmpfr-X.dll, etc).
I don't recommend that, for obvious reasons -- the mingw compiler should
be standalone [e.g. linked statically against external or built-in-tree
libs].  But I could see cases where officially distributed packages
might have DLL dependencies on other officially distributed packages.

Now, if I go and update the latest gettext to 0.19 which bumps the
libintl DLL number to "9", then what happens to those dependent packages?

If the DLL is contained within the "regular" gettext package (e.g -bin,
in Keith's original scheme) with the utilities, then in any normal
package management system [*] the user must choose between "old gettext
with the DLL that this other package 'foo' requires" or "new gettext
with fancy features and bugfixes but breaks 'foo'"

[*] "Just untar stuff on top of each other and never clean up" is not a
normal package management system, although it does avoid the problem
described above. However, it has so many other problems I can't even
begin to describe...



Furthermore, the -dll package ought to include a version number as well
(just like .debs, .rpms, and yes, even cygwin packages do, for shared
libraries). This way, a normal package management system will not
complain if two different -dll packages are both installed at the same
time (they won't be viewed as 'replacement/updates'):
   e.g: [<<<< HERE >>>>]
     gettext-0.16.1-1-dll8.tar.gz --> libintl-8.dll
     gettext-0.16.2-1-dll8.tar.gz --> libintl-8.dll
      This is an update

     gettext-0.16.2-1-dll8.tar.gz --> libintl-8.dll
     gettext-0.17.0-1-dll9.tar.gz --> libintl-9.dll
      These are *different* packages, providing *different* dlls.
      They don't clobber each other, and regular package management
      systems will allow both to be simultaneously installed.

It is a little odd that part of the "package name" is at the beginning
of the string, and part of it is at the end:

     gettext-[VERSION-STUFF]-dll8 --> gettext-dll8 = package name
     gettext-[VERSION-STUFF]-dev  --> gettext-dev  = package name
     gettext-[VERSION-STUFF]-bin  --> gettext-bin  = package name
     gettext-[VERSION-STUFF]-src  --> gettext-src  = package name

But that's okay. As long as it is consistent, we're good.


On those other systems, the split-up package names describe their
contents, and not necessarily the -src from which they came.  Plus, the
package-name is strictly at the beginning of the filename [with the
exception of -src or .src.rpm].  That is, (on cygwin at least):

gettext-0.15-1-src.tar.bz2

gettext-0.15-1.tar.bz2
    normal tools; Bruno calls this "gettext-runtime" except that
    cygwin doesn't include the public DLLs here)

gettext-devel-0.15-1.tar.bz2
    development tools (Bruno also calls this "gettext-devel" except
    cygwin doesn't include the private DLLs here)

libintl8-0.15-1.tar.bz2
    contains cygintl-8.dll
    Note the name doesn't even say 'gettext', but does include '8'

libasprintf0-0.15-1.tar.bz2
    contains cygasprintf-0.dll, a 'standalone' utility library
    distributed as part of gettext, but it isn't used by any
    gettext binaries, nor does it depend on any other gettext
    libraries.  It's really a separate tool...

libgettextpo0-0.15-1.tar.bz2
    This one is interesting. cyggettextpo-0.dll is the "public"
    interface to some useful utility code. Internally, it is a wrapper
    around versioned (private) dlls:
      cyggettextlib-0-15.dll
      cyggettextsrc-0-15.dll
    which are used directly by the tools in gettext-devel-0.15-1


However, I don't think that MSys/MinGW requires this level of
granularity, and IMO the FRS makes maintaining this sort of multi-named
dependency really awkward.  Plus, the whole 'hey you're violating the
GPL where is "libintl8-src.tar.bz2"' ==> 'it's in gettext-src.tar.bz2'
is not something we want to deal with.

So, to sum up, here's how I would (now) package the updated, mingw
gettext derivatives:

gettext-0.16.1-1-src.tar.bz2
    contains actual upstream src, maybe pre-modified for mingw if
necessary, or maybe with included patches to-be-applied. Also maybe
contains build script or instructions specific to mingw. Or maybe it's
just a mingwPORT + the actual source -- since I'm distributing actual
binaries, I can't ONLY distribute a mingwPORT, must include source, too.

gettext-0.16.1-1-bin.tar.bz2
    analogous to cygwin's 'gettext' package (e.g. Bruno's
'gettext-runtime' without the DLLs)

gettext-0.16.1-1-dev.tar.bz2
   analogous to cygwin's 'gettext-devel' package (e.g. Bruno's
'gettext-devel' without the private DLLs)

gettext-0.16.1-1-dll8.tar.bz2
   contains all of the DLLs, public and private:
      libgettextlib-0-16-1.dll
      libgettextsrc-0-16-1.dll
      libasprintf-0.dll
      libgettextpo-0.dll
      libintl-8.dll
   Now, what should the "version number" of this -dll package be? 0, 8,
0-16-1? 0+8+0+16+1 = 25?  I arbitrarily chose "the version number of the
'most important' DLL" -- because nobody really cares about libgettextpo,
libasprintf is extremely stable, and  libgettext[src|lib] are private
anyway.

Now, go back up to [<<<< HERE >>>>], and think about this -dll8 package
that contains five different DLLs.  I'll wait...

=====
If there were ever an API change in libgettextpo (resulting in
libgettextpo-1.dll) without a corresponding API change/dllnumber bump in
"the important" library, I'm in trouble.

But:

(a) that's extremely unlikely

(b) I can create a "stub" package pair for the orphaned lib at that time:
        libgettextpo0-VER-REL-dll0.tar.gz
        libgettextpo0-VER-REL-src.tar.gz === original
gettext-VER-REL-src.tar.gz from which this old libgettextpo0 came.

=====

Now, consider the second scenaria at [<<<< HERE >>>>]. If libintl
changes -- both the -dll8 and -dll9 packages are both going to contain
libasprintf-0.dll whose API did not change. UGH -- package management
confict!

However:
(a) cross that bridge when we come to it
(b) We don't actually HAVE a sane package management system yet -- and
might not ever have one
(c) Even if we did have a package management system, but chose to ignore
this particular problem, the problems will be isolated to a few easily
identifiable -dll packages...where's that handy FAQ page on the wiki...

=====

In any event, gettext is a pathological example of DLL version numbering
intersecting with package naming conventions.  I doubt ANY other
"official" package, except gcc-with-shared-runtimes, will distribute
multiple DLLs whose version numbers are not guaranteed to stay in sync.

But we ought to think about *separate* packages for the gcc shared
runtimes...for both sjlj and dw2 variants </me runs for the door>

--
Chuck


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Keith, Chuck,

Charles Wilson wrote:
 > Keith Marshall wrote:
 >> We should specify a minimal, well defined set.  I suggest:
...
 > I'd suggest *routinely* splitting
 > DLLs into a -dll package, separate from the -bin, even when a -bin
 > package could contain the DLLs and other executables.

I read Chuck's message, but what I didn't really understand the original
reason splitting up a single build of a single piece of software is
valuable.

The only reason we split -bin and -src in the first place is to save
network transfer and disk space, as far as I know.


The MSYS and MinGW-ports side of things may demand additional
complexity; so if you're talking only about them, OK.  But I'd prefer if
the core MinGW packages (mingwrt, w32api, binutils, gcc) didn't have any
more packaging complexity than necessary.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr