[Mingw-users] mingw32-gdb license package issue

[Hoyt, David <hoyt6@ll...>]

The mingw32-gdb package also seems to have license issues. Here's what I get:


$ mingw-get --all-related licence mingw32-gdb

mingw-get.exe: *** WARNING *** http://prdownloads.sourceforge.net/mingw/gdb-7.3.1-1-mingw32-lic.tar.lzma?download: opened with unexpected status: code = 404
mingw-get.exe: *** WARNING *** please report this to the mingw-get maintainer
mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/gdb-7.3.1-1-mingw32-lic.tar.lzma?download: download failed


Oddly enough, running "mingw-get licence mingw32-gdb" doesn't result in an error.

Re: [Mingw-users] Default return value for functions.

[Mark Wagner <carnildo@gm...>]

On Wed, Nov 2, 2011 at 11:20, Mani <manips2002@...> wrote:
> Hi,
>
> Is there a default return value defined for functions?
> For instance, I write an int function (function that is supposed to
> return an int), or a double function, but I forget to return a value.
>
> still something gets returned -- how is that return value defined, if at all?

Typically, the compiler will specify a memory location to store the
return value in (the details depend on the calling convention in use);
if you don't include a "return" statement, the memory location will be
uninitialized, and the function's return value will be impossible to
predict.

-- 
Mark Wagner

Re: [Mingw-users] msys-bsdtar and mingw-developer-toolkit contents [Was: Updated: msys-xz-5.0.3-1]

[Charles Wilson <cwilso11@us...>]

On 11/8/2011 4:24 PM, Keith Marshall wrote:
> On 08/11/11 17:48, Charles Wilson wrote:
>> I was
>> thinking that mingw-get could use libarchive to support its operation.
> 
> And, at the time, I'd hoped to use it, but as I recall, there were just
> too many unresolved issues for a MinGW build, and you yourself advised
> me to follow...
> 
>> As it happened, mingw-get ... and implements ONLY 'tar' format
>> (de)archive support -- and does so internally.  So, it doesn't use
>> libarchive.
> 
> ...this alternative course.  (In fact, I did base the tar extraction
> code on libarchive's bootstrap extractor, and integrated it with my own
> decompression classes, using liblzma, libz, and libbz2).

And that's fine; I wasn't being critical.  Cygwin's setup.exe follows
the same course, because it needs to analyze the path, symlink,
permissions, and ownership information directly before writing the files
to disk -- I'm not sure that libarchive's interface provides that
flexibility.

Back then, when mingw-get was still just a gleam in your eye, we didn't
know what we do now -- about mingw-get's needs in detail, and about
libarchive's capabilities.  Also, we had a chicken-egg problem: we
needed to split MEGA_TARBALL into about 50 different packages, each with
three to five components, for a total of over 200 tarballs ... so that
mingw-get would have something to operate on, prior to deploying
mingw-get itself.

But...could anyone actually bootstrap that system -- unpack those
tarballs -- prior to mingw-get's advent?  On a bare system with no
pre-existing cygwin or msys?  I remember we looked at 7zip and various
other tools, before I eventually published basic-bsdtar...

>> ... we don't, actually, need libarchive.a [I thought we would, but
>> mingw-get went another direction].
> 
> One day, we might revisit that decision, but for the foreseeable future
> I think what we have in mingw-get is sufficient for our needs -- there
> is still a significant development effort required, with a much greater
> urgency than adopting libarchive, or adding support for any arbitrary
> set of additional archive formats.

Big Ack on that one.

--
Chuck

Re: [Mingw-users] mingw-get source missing package

[Hoyt, David <hoyt6@ll...>]

> This looks like another bug in the manifest.  

These things happen to everyone. Thanks for looking into it so quickly -- it's much appreciated. 

Have the catalogs been updated then?


> Thanks for the report.

Happy to help in what little way I can. Everyone's hard work and long hours on the project is much appreciated -- please remember that and don't forget that your community supports all that you do!

Cheers,
- David

Re: [Mingw-users] mingw-get source missing package

[Keith Marshall <keithmarshall@us...>]

On 08/11/11 20:25, Keith Marshall wrote:
> On 08/11/11 20:10, Earnie wrote:
>>> This looks like another bug in the manifest.  msys-core.xml SHOULD say this:
>>> 
>>>      <source tarname="msysCORE-%-msys-%-src.tar.%" />
>>>      <licence tarname="msysCORE-%-msys-%-lic.tar.%" />
>> 
>> It does in CVS; maybe it didn't make the FRS release.
> 
> Which suggests that my sed regex worked, and it was the bulk sftp upload
> which choked.

In fact, my own sandbox copies show that the sed substitution had been
correctly applied in each of these three cases:

>>> 	msys-core   -- Cesar
>>> 	msys-bash   -- me
>>> 	msys-mintty -- Andy

I've pushed them to FRS again.

-- 
Regards,
Keith.

Re: [Mingw-users] msys-bsdtar and mingw-developer-toolkit contents [Was: Updated: msys-xz-5.0.3-1]

[Keith Marshall <keithmarshall@us...>]

On 08/11/11 17:48, Charles Wilson wrote:
> So, originally, mingw32-bsdtar (well, actually, mingw32-libarchive) was
> provided for two reasons: (1) because it'd be a nice addition for those
> who wanted to use only native tools with no MSYS, but for whom the very
> limited basic-bsdtar was insufficient, and (2) because it came for
> "free" with mingw32-libarchive, and (at the time, pre-mingw-get) I was
> thinking that mingw-get could use libarchive to support its operation.

And, at the time, I'd hoped to use it, but as I recall, there were just
too many unresolved issues for a MinGW build, and you yourself advised
me to follow...

> As it happened, mingw-get instead uses liblzma, libz, and libbz2
> directly for (de)compression support, and implements ONLY 'tar' format
> (de)archive support -- and does so internally.  So, it doesn't use
> libarchive.

...this alternative course.  (In fact, I did base the tar extraction
code on libarchive's bootstrap extractor, and integrated it with my own
decompression classes, using liblzma, libz, and libbz2).

> ... we don't, actually, need libarchive.a [I thought we would, but
> mingw-get went another direction].

One day, we might revisit that decision, but for the foreseeable future
I think what we have in mingw-get is sufficient for our needs -- there
is still a significant development effort required, with a much greater
urgency than adopting libarchive, or adding support for any arbitrary
set of additional archive formats.

-- 
Regards,
Keith.

Re: [Mingw-users] msys-bsdtar and mingw-developer-toolkit contents [Was: Updated: msys-xz-5.0.3-1]

[Earnie <earnie@us...>]

Charles Wilson wrote:
> On 11/8/2011 9:56 AM, Earnie wrote:
>>> (although msys-bsdtar is included in mingw-developer-toolkit; it
>>
>> I don't think it should be.
> 
> You know, there was a time when we discussed all these things, and
> talked about what packages should and should not be included in
> msys-base, mingw-developer-toolkit, etc.
> 
> http://thread.gmane.org/gmane.comp.gnu.mingw.devel/4058/focus=4078
> 

It appears that I was silent.

> I'm starting to get a little frustrated by all this second guessing. A
> few days ago it was about the contents of msys-base.  Now it's about the
> contents of mingw-developer-toolkit. And the rehashing keeps popping up
> as threadjacks, which is doubly annoying.
> 

Hardly, intended to frustrate you.

> 
> But you seem initially to be asserting a stronger propostion: not simply
> that msys-bsdtar (msys-bsdpio, msys-libarchive) be removed from
> mingw-developer-toolkit going forward, but that they be removed from
> mingw.org entirely.  I mildly disagree with the former (obviously), but
> strongly disagree with the latter.
> 

No, just trying more to understand why we need more than one tar.  Since
msys-bsdtar supplies all that is needed for MinGW why not just use it
and drop msys-tar?  Or if that is too much then just leave it to the
user to grab it.  I found it amusing that David Hoyt states he uses
mingw32-bsdtar in his mail relating to missing dependencies and as you
state he should be using msys-bsdtar.

>>> supports more formats than GNU tar, including .iso (readonly), .cpio,
>>> .zip, mtree, shar, ...).
>>
>> This becomes a better reason to have it but still not a good enough
>> reason to include it in the DTK.
> ...
>> Okay, I've not ever had a need to use bsdtar in MSYS.
> 
> I did, back when msys-tar was 1.13 or so.  At the time we (a) did not
> yet have a mingw-get installer, and (b) many of our packages still had
> very strange internal structure. Some "binary" packages were
> bob-1.2.3/{bin/*,share/*,lib/*}, others were mingw/{bin,share/lib}, and
> still others were /bin,/share,/lib.
> 
> So...IIRC, bsdtar supported '--strip-components=N' and our old version
> of tar did not -- plus there were early issues with gnu tar + lzma (e.g.
> I think you had to do 'tar --use-compress-program=lzma' or something
> ugly like that).

Ack.

> 
>> And having mingw32-bsdtar, installing msys-bsdtar becomes needless
>> because mingw32-bsdtar would always be found first unless you're
>> developing in MSYS developer mode giving another issue to including it
>> in the DTK.
> 
> Not exactly -- first, because while msys-bsdtar is currently installed
> as part of the mingw-developer-toolkit, mingw32-bsdtar is not.
> Therefore, "typical" users who invoke 'bsdtar' from an msys shell, even
> in its normal "Hi-I'm-mingw32" mode, would get the msys version.  Only
> those who explicitly select and install the mingw32 version would get
> it.  Presumably they did so for a reason, and get to keep all the pieces
> if something breaks.
> 

So, the announcement entices the MinGW user to install both
mingw32-bsdtar and msys-bsdtar.

> Secondly, because some features of bsdtar (actually, libarchive, but
> let's not quibble) require external libraries for which we (had/have) no
> mingw32 version (e.g. expat at first, plus openssl), the msys-bsdtar is
> more featureful than the mingw one.
> 

Ok, so there are dependencies in msys-bsdtar that aren't delivered in
msys-base which is a reason to have both msys-tar and msys-bsdtar.

>> The DTK was developed for tools typically needed for
>> development and a native version wasn't easily usable within MSYS.
> 
> With regards to bsdtar, I viewed it the other way around: because we had
> support for (libxml, libexpat, openssl) under msys, I could build a
> full-featured version that passed almost all of its internal testsuite
> and skipped very little.  In fact, I joined the project, helped to
> rewrite most of its build system -- while arguing for retaining the
> autotool based system rather than deprecating that in favor of cmake --
> and got it patched to support cygwin, msys, and mingw  (ditto for xz, BTW).
> 

Ack.

> But, for those who wanted more-than-basic-bsdtar AND wanted to avoid
> MSYS, I could provide a tar(1) implementation for them that was *fairly*
> complete, but still had significant weaknesses when compared to the
> "real" one -- that is, msys-bsdtar:
> 
>    1) no support for .mtree (later slightly relaxed, once mingw32
>       subsys gained mingw32-libexpat; but still no support for
>       cryptographic hashes because no openssl)
>    2) no support for archives which contain symbolic links; IIRC
>       mingw32-bsdtar will exit with error if you try to unpack one...
>    3) no support for xar (later relaxed, with addition of mingw32-
>       libexpat)
> 

Ack.

> So, originally, mingw32-bsdtar (well, actually, mingw32-libarchive) was
> provided for two reasons: (1) because it'd be a nice addition for those
> who wanted to use only native tools with no MSYS, but for whom the very
> limited basic-bsdtar was insufficient, and (2) because it came for
> "free" with mingw32-libarchive, and (at the time, pre-mingw-get) I was
> thinking that mingw-get could use libarchive to support its operation.
> 
> As it happened, mingw-get instead uses liblzma, libz, and libbz2
> directly for (de)compression support, and implements ONLY 'tar' format
> (de)archive support -- and does so internally.  So, it doesn't use
> libarchive.
> 
> IMO, the argument between msys-bsdtar and mingw32-bsdtar is just like
> the "argument" between msys-bzip2 and mingw32-bzip2: if we have
> mingw32-bzip2, why not just remove msys-bzip2?  Except that misses an
> important issue, which applies in both the bzip2 and bsdtar cases: the
> mingw32 *application* is, in many ways, a *side effect* of needing the
> *library* for that subsystem.  E.g. mingw-get needs (mingw32)libbz2.a --
> and we get (mingw32)bzip2.exe "for free" -- but that doesn't supplant
> the msys-bzip2, because bzip2.exe is often used in pipelines, and those
> just plain work better if both 'sides' of the pipe are msys -- error
> return value propagation, etc.
> 

Good points - Ack.

> Ditto liblzma/xz. Ditto ditto (mingw32)libarchive.a and
> (mingw32)bsdtar.exe -- except that we don't, actually, need libarchive.a
> [I thought we would, but mingw-get went another direction].
> 

Good points for -dev but not exactly -bin.

> =====
> 
> I believe that all four 'tar' implementations are complimentary, and
> fulfill different needs.  In a *basic* msys installation, gnu tar is the
> obvious choice, as the *nix de-facto standard.  In a development
> environment, our users might have need of the extensive alternative
> formats that msys-bsdtar provides (ever wanted to poke around in the
> contents of an .iso on win32, without installing a Windows Driver and
> 'mounting' it?)
> 

Ack.

> Some users may wish to eschew MSYS altogether, but still need a
> relatively capable tar(1) implementation -- for those users,
> mingw32-bsdtar is the answer.
> 
> And finally, sometimes you just need a quick and dirty self-contained
> tool to unpack .tar.[gz|bz2|lzma|xz] on a windows box, and don't want
> to, don't need to, or are not allowed to, install a mingw32 or MSYS
> environment. That's what basic-bsdtar.exe is for.
> 
> However, if one of those four were to be removed from mingw.org, I'd
> argue that mingw32-libarchive/bsdtar should be the one, not
> msys-libarchive/bsdtar.

Given that one might not want MSYS, I can see leaving both.  But your
points and mine bring up the question of mingw-get needing a <conflicts
/> tag?  While mingw32-libarchive is needed for possible MinGW
development msys-bsdtar should be the choice for the user wanting more
decompression options in a tar and mingw32-bsdtar would get in the way
if both are installed.  Your lengthy response gives someone who may need
to take over one day for Chuck some reasoning behind it.

Regards,
-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] mingw-get source missing package

[Keith Marshall <keithmarshall@us...>]

On 08/11/11 20:10, Earnie wrote:
>> This looks like another bug in the manifest.  msys-core.xml SHOULD say this:
>> 
>>      <source tarname="msysCORE-%-msys-%-src.tar.%" />
>>      <licence tarname="msysCORE-%-msys-%-lic.tar.%" />
> 
> It does in CVS; maybe it didn't make the FRS release.

Which suggests that my sed regex worked, and it was the bulk sftp upload
which choked.

-- 
Regards,
Keith.

Re: [Mingw-users] mingw-get source missing package

[Keith Marshall <keithmarshall@us...>]

On 08/11/11 19:40, Charles Wilson wrote:
> this was a recent mingw-get requirement change, and I thought we updated
> all the affected manifests but looks like we missed a few:

Well, I just blitzed the entire corpus with a sed regex substitution...

> 	msys-core   -- Cesar
> 	msys-bash   -- me
> 	msys-mintty -- Andy

...so I guess these three didn't match for some reason, and I failed
to notice.  Or, the wild card sftp upload I followed up with choked on
these three, and I failed to notice that.  Apologies.

> Thanks for the report.

Seconded.

-- 
Regards,
Keith.

Re: [Mingw-users] mingw-get source missing package

[Earnie <earnie@us...>]

Charles Wilson wrote:
> On 11/8/2011 2:08 PM, Hoyt, David wrote:
>> Here’s a command I issued and the resulting error message:
>>
>> $ mingw-get --all-related source msys-vim
>>
>> mingw-get.exe: *** WARNING ***
>> http://prdownloads.sourceforge.net/mingw/msysCORE-1.0.17-1-msys-1.0.17-src.tar?download:
>> opened with unexpected status: code = 404
>>
>> mingw-get.exe: *** WARNING *** please report this to the mingw-get
>> maintainer
>>
>> mingw-get.exe: *** ERROR *** Get package:
>> http://prdownloads.sourceforge.net/mingw/msysCORE-1.0.17-1-msys-1.0.17-src.tar?download:
>> download failed
> 
> This looks like another bug in the manifest.  msys-core.xml SHOULD say this:
> 
>      <source tarname="msysCORE-%-msys-%-src.tar.%" />
>      <licence tarname="msysCORE-%-msys-%-lic.tar.%" />
> 

It does in CVS; maybe it didn't make the FRS release.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] mingw-get source missing package

[Charles Wilson <cwilso11@us...>]

On 11/8/2011 2:08 PM, Hoyt, David wrote:
> Here’s a command I issued and the resulting error message:
> 
> $ mingw-get --all-related source msys-vim
> 
> mingw-get.exe: *** WARNING ***
> http://prdownloads.sourceforge.net/mingw/msysCORE-1.0.17-1-msys-1.0.17-src.tar?download:
> opened with unexpected status: code = 404
> 
> mingw-get.exe: *** WARNING *** please report this to the mingw-get
> maintainer
> 
> mingw-get.exe: *** ERROR *** Get package:
> http://prdownloads.sourceforge.net/mingw/msysCORE-1.0.17-1-msys-1.0.17-src.tar?download:
> download failed

This looks like another bug in the manifest.  msys-core.xml SHOULD say this:

     <source tarname="msysCORE-%-msys-%-src.tar.%" />
     <licence tarname="msysCORE-%-msys-%-lic.tar.%" />

(note the trailing .%) -- but instead it says this:

     <source tarname="msysCORE-%-msys-%-src.tar" />
     <licence tarname="msysCORE-%-msys-%-lic.tar" />

this was a recent mingw-get requirement change, and I thought we updated
all the affected manifests but looks like we missed a few:

	msys-core   -- Cesar
	msys-bash   -- me
	msys-mintty -- Andy

Thanks for the report.

--
Chuck

Re: [Mingw-users] mingw-get package missing dependencies

[Charles Wilson <cwilso11@us...>]

On 11/8/2011 2:15 PM, Hoyt, David wrote:
> I believe msys-gettext (or whatever package msgfmt.exe is in) or one
> of its dependencies is missing a declared dependency on libgomp and
> libstdc++. When I create an msys setup without gcc (I use one I compiled
> myself), those dependencies aren't pulled in and don't exist. Presumably
> this wasn't discovered because most folks using msys/mingw are also
> using the supplied gcc. The following are the packages I typically use
> to setup my msys/mingw environment:
...
> I had to add libgomp and libstdc++ to get it to work.

Yep, that's a bug in the manifest. gettext-dev should depend on
libstdc++, because all of those .exe's are linked using C++ as part of
Bruno's WOE32 build procedure (the .exe's in gettext-bin are not linked
that way).  Also, msgmerge.exe -- but none of the other tools --
requires libgomp.

Thanks for the report.

--
Chuck

[Mingw-users] mingw-get package missing dependencies

[Hoyt, David <hoyt6@ll...>]

I believe msys-gettext (or whatever package msgfmt.exe is in) or one of its dependencies is missing a declared dependency on libgomp and libstdc++. When I create an msys setup without gcc (I use one I compiled myself), those dependencies aren't pulled in and don't exist. Presumably this wasn't discovered because most folks using msys/mingw are also using the supplied gcc. The following are the packages I typically use to setup my msys/mingw environment:


msys-autoconf     msys-autogen      msys-automake     msys-bash         msys-binutils 
msys-bison        msys-bzip2        msys-console      msys-core         msys-coreutils 
msys-crypt        msys-cvs          msys-cygutils     msys-dash         msys-diffutils 
msys-expat        msys-file         msys-flex         msys-gawk         msys-locate 
msys-gdbm         msys-gettext      msys-gmp          msys-grep         msys-groff 
msys-guile        msys-gzip         msys-inetutils    msys-less         msys-libarchive 
msys-libiconv     msys-libtool      msys-libxml2      msys-lndir        msys-lpr-enhanced 
msys-m4           msys-make         msys-man          msys-minires      msys-mintty 
msys-mktemp       msys-openssh      msys-openssl      msys-patch        msys-zlib 
msys-popt         msys-rebase       msys-regex        msys-rxvt         msys-sed 
msys-tar          msys-termcap      msys-texinfo      msys-unzip        msys-vim 
msys-wget         msys-xz           msys-zip          msys-autogen      msys-findutils 
msys-perl         

mingw32-autotools mingw32-make      mingw32-gdb       mingw32-bsdtar    mingw32-gendef 
mingw-get


I had to add libgomp and libstdc++ to get it to work.

Cheers,
- David Hoyt

[Mingw-users] mingw-get source missing package

[Hoyt, David <hoyt6@ll...>]

Hi there,

Here's a command I issued and the resulting error message:

$ mingw-get --all-related source msys-vim

mingw-get.exe: *** WARNING *** http://prdownloads.sourceforge.net/mingw/msysCORE-1.0.17-1-msys-1.0.17-src.tar?download: opened with unexpected status: code = 404
mingw-get.exe: *** WARNING *** please report this to the mingw-get maintainer
mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/msysCORE-1.0.17-1-msys-1.0.17-src.tar?download: download failed
http://prdownloads.sourceforge.net/mingw/libiconv-1.14-1-msys-1.0.17-src.tar.lzma?download
4.20 MB / 4.20 MB       |================================================| 100%
http://prdownloads.sourceforge.net/mingw/termcap-0.20050421_1-2-msys-1.0.13-src.tar.lzma?download
67.83 kB / 67.83 kB     |================================================| 100%
http://prdownloads.sourceforge.net/mingw/gettext-0.18.1.1-1-msys-1.0.17-src.tar.lzma?download
14.41 MB / 14.41 MB     |================================================| 100%
http://prdownloads.sourceforge.net/mingw/vim-7.3-2-msys-1.0.16-src.tar.lzma?download
6.68 MB / 6.68 MB       |================================================| 100%

As you can see, other package sources download fine, but msys core seems to be having problems. I issued the command again just to be sure that there wasn't some CDN issue - but it failed with the same error. Just wanted to bring this to your attention.

[Mingw-users] msys-bsdtar and mingw-developer-toolkit contents [Was: Updated: msys-xz-5.0.3-1]

[Charles Wilson <cwilso11@us...>]

On 11/8/2011 9:56 AM, Earnie wrote:
>> (although msys-bsdtar is included in mingw-developer-toolkit; it
> 
> I don't think it should be.

You know, there was a time when we discussed all these things, and
talked about what packages should and should not be included in
msys-base, mingw-developer-toolkit, etc.

http://thread.gmane.org/gmane.comp.gnu.mingw.devel/4058/focus=4078

I'm starting to get a little frustrated by all this second guessing. A
few days ago it was about the contents of msys-base.  Now it's about the
contents of mingw-developer-toolkit. And the rehashing keeps popping up
as threadjacks, which is doubly annoying.


But you seem initially to be asserting a stronger propostion: not simply
that msys-bsdtar (msys-bsdpio, msys-libarchive) be removed from
mingw-developer-toolkit going forward, but that they be removed from
mingw.org entirely.  I mildly disagree with the former (obviously), but
strongly disagree with the latter.

>> supports more formats than GNU tar, including .iso (readonly), .cpio,
>> .zip, mtree, shar, ...).
> 
> This becomes a better reason to have it but still not a good enough
> reason to include it in the DTK.
...
> Okay, I've not ever had a need to use bsdtar in MSYS.

I did, back when msys-tar was 1.13 or so.  At the time we (a) did not
yet have a mingw-get installer, and (b) many of our packages still had
very strange internal structure. Some "binary" packages were
bob-1.2.3/{bin/*,share/*,lib/*}, others were mingw/{bin,share/lib}, and
still others were /bin,/share,/lib.

So...IIRC, bsdtar supported '--strip-components=N' and our old version
of tar did not -- plus there were early issues with gnu tar + lzma (e.g.
I think you had to do 'tar --use-compress-program=lzma' or something
ugly like that).

> And having mingw32-bsdtar, installing msys-bsdtar becomes needless
> because mingw32-bsdtar would always be found first unless you're
> developing in MSYS developer mode giving another issue to including it
> in the DTK.

Not exactly -- first, because while msys-bsdtar is currently installed
as part of the mingw-developer-toolkit, mingw32-bsdtar is not.
Therefore, "typical" users who invoke 'bsdtar' from an msys shell, even
in its normal "Hi-I'm-mingw32" mode, would get the msys version.  Only
those who explicitly select and install the mingw32 version would get
it.  Presumably they did so for a reason, and get to keep all the pieces
if something breaks.

Secondly, because some features of bsdtar (actually, libarchive, but
let's not quibble) require external libraries for which we (had/have) no
mingw32 version (e.g. expat at first, plus openssl), the msys-bsdtar is
more featureful than the mingw one.

> The DTK was developed for tools typically needed for
> development and a native version wasn't easily usable within MSYS.

With regards to bsdtar, I viewed it the other way around: because we had
support for (libxml, libexpat, openssl) under msys, I could build a
full-featured version that passed almost all of its internal testsuite
and skipped very little.  In fact, I joined the project, helped to
rewrite most of its build system -- while arguing for retaining the
autotool based system rather than deprecating that in favor of cmake --
and got it patched to support cygwin, msys, and mingw  (ditto for xz, BTW).

But, for those who wanted more-than-basic-bsdtar AND wanted to avoid
MSYS, I could provide a tar(1) implementation for them that was *fairly*
complete, but still had significant weaknesses when compared to the
"real" one -- that is, msys-bsdtar:

   1) no support for .mtree (later slightly relaxed, once mingw32
      subsys gained mingw32-libexpat; but still no support for
      cryptographic hashes because no openssl)
   2) no support for archives which contain symbolic links; IIRC
      mingw32-bsdtar will exit with error if you try to unpack one...
   3) no support for xar (later relaxed, with addition of mingw32-
      libexpat)

So, originally, mingw32-bsdtar (well, actually, mingw32-libarchive) was
provided for two reasons: (1) because it'd be a nice addition for those
who wanted to use only native tools with no MSYS, but for whom the very
limited basic-bsdtar was insufficient, and (2) because it came for
"free" with mingw32-libarchive, and (at the time, pre-mingw-get) I was
thinking that mingw-get could use libarchive to support its operation.

As it happened, mingw-get instead uses liblzma, libz, and libbz2
directly for (de)compression support, and implements ONLY 'tar' format
(de)archive support -- and does so internally.  So, it doesn't use
libarchive.

IMO, the argument between msys-bsdtar and mingw32-bsdtar is just like
the "argument" between msys-bzip2 and mingw32-bzip2: if we have
mingw32-bzip2, why not just remove msys-bzip2?  Except that misses an
important issue, which applies in both the bzip2 and bsdtar cases: the
mingw32 *application* is, in many ways, a *side effect* of needing the
*library* for that subsystem.  E.g. mingw-get needs (mingw32)libbz2.a --
and we get (mingw32)bzip2.exe "for free" -- but that doesn't supplant
the msys-bzip2, because bzip2.exe is often used in pipelines, and those
just plain work better if both 'sides' of the pipe are msys -- error
return value propagation, etc.

Ditto liblzma/xz. Ditto ditto (mingw32)libarchive.a and
(mingw32)bsdtar.exe -- except that we don't, actually, need libarchive.a
[I thought we would, but mingw-get went another direction].

=====

I believe that all four 'tar' implementations are complimentary, and
fulfill different needs.  In a *basic* msys installation, gnu tar is the
obvious choice, as the *nix de-facto standard.  In a development
environment, our users might have need of the extensive alternative
formats that msys-bsdtar provides (ever wanted to poke around in the
contents of an .iso on win32, without installing a Windows Driver and
'mounting' it?)

Some users may wish to eschew MSYS altogether, but still need a
relatively capable tar(1) implementation -- for those users,
mingw32-bsdtar is the answer.

And finally, sometimes you just need a quick and dirty self-contained
tool to unpack .tar.[gz|bz2|lzma|xz] on a windows box, and don't want
to, don't need to, or are not allowed to, install a mingw32 or MSYS
environment. That's what basic-bsdtar.exe is for.

However, if one of those four were to be removed from mingw.org, I'd
argue that mingw32-libarchive/bsdtar should be the one, not
msys-libarchive/bsdtar.

--
Chuck

Re: [Mingw-users] gcc-4.6.1 no specs file delivered

[Earnie <earnie@us...>]

Keith Marshall wrote:
> On 8 November 2011 02:02, Cesar Strauss wrote:
>> On 11/07/2011 01:01 PM, Earnie wrote:
>>
>>> Has the procedure to deliver a specs file by default changed upstream or
>>> is this a MinGW issue?
>>
>> GCC 3.4.5 has the specs file, but it's gone already in 4.2.1.
> 
> IIRC, upstream discontinued shipping of an external specs file for ALL
> 4.x releases, favouring built-in specs instead.
> 

I thought as much but wanted to confirm I wasn't being insane about it.

Regards,
-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] Updated: msys-xz-5.0.3-1

[Earnie <earnie@us...>]

Charles Wilson wrote:
> On 11/7/2011 9:55 AM, Earnie wrote:
>> I question the need for msys-bsdtar??  It seems msys-tar provides the
>> extraction and creation of lzma as well as xz.  I've begun to use the
>> -a, --auto-compress flag to tar for both creation and extraction.
>> However, msys-tar must use a static xz library.
> 
> No, actually GNU tar delegates to external binaries, and uses pipes.
> That is, GNU tar uses gzip.exe, bzip2.exe, lzma.exe -- this is why

Oh, yea, right.

> GnuWin32's port of GNU tar is dain-bramaged, and cannot deal with
> compressed tarballs (no fork()+pipes emulation).  

Ack.

> It's also why I ported
> libarchive (aka bsdtar) to msys/mingw32 in the first place...so we could
> have a mingw32-(basic-)bsdtar on win32 that could handle compressed
> tarballs.  This goes back to our long painful discussion from three
> years ago about compression formats for "the installer", where we
> settled on .lzma and --hard-dereference...
> 

Ack.

> 
> FWIW, msys-bsdtar is not part of msys-base -- GNU msys-tar is.

Ack.

> (although msys-bsdtar is included in mingw-developer-toolkit; it

I don't think it should be.

> supports more formats than GNU tar, including .iso (readonly), .cpio,
> .zip, mtree, shar, ...).

This becomes a better reason to have it but still not a good enough
reason to include it in the DTK.

>>From msys-libarchive.xml:
> =================================
> ...It also supports archives that contain symbolic links by converting
> them to equivalent hardlink (or recursive copy) representations (see
> below).  The MinGW implementation does not support archives with
> symbolic links, nor mtree data...
> 
> This msys implementation has some unique behaviors with regards to
> symbolic and hard links.  When creating archives on an MSYS platform,
> there are no symbolic links; hardlinks are archived as on unix, without
> requiring duplicate storage (unless the --hard-dereference option is
> used).  When extracing archives on an MSYS platform, if the archive
> contains hardlinks then they are reproduced on the local file system
> provided the Win32 filesystem supports hardlinks (e.g. NTFS; on FAT, a
> duplicate copy of the file is created).  If the archive contains
> symbolic links where the target is a file contained within the archive
> itself, then those links are reproduced as if they were hardlinks, as
> described above.  "Dangling" symbolic links are not supported.  Symbolic
> links to directories within the archive are "supported", by creating a
> recursive copy of the target directory, where the contents of the
> directory are treated as hardlinks as described above.

Okay, I've not ever had a need to use bsdtar in MSYS.

> 
>>From mingw32-basic-bsdtar.xml:
> =================================
> The mingw32-basic-bsdtar package provides an implementation of tar(1)
> for native Win32 platforms that is statically linked -- that is, has no
> dependencies on external DLLs other than those provided by the Win32
> platform.  basic-bsdtar has somewhat limited functionality compared to
> the other versions of bsdtar provided by the MinGW/MSYS project
> (msys-bsdtar and mingw32-bsdtar).  However, it supports tar archives in
> the ustar, pax, and gnutar formats, compressed using gzip, bzip2, lzma,
> or xz.
> 

And having mingw32-bsdtar, installing msys-bsdtar becomes needless
because mingw32-bsdtar would always be found first unless you're
developing in MSYS developer mode giving another issue to including it
in the DTK.  The DTK was developed for tools typically needed for
development and a native version wasn't easily usable within MSYS.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] Libtool, --disable-static --enable-shared, make check

[Earnie <earnie@us...>]

Charles Wilson wrote:
> On 11/7/2011 3:48 PM, Earnie wrote:
>> But I find that PATH is mucked incorrect to add ../src/.libs to the PATH
>> in that the value added is
>> \usr\src\FOO\.libs:c:\mingw\bin;c:\whatever\else which is obviously a
>> bug in LIBTOOL.
> 
> Ah, well ... then I need to know more about your dev environment.
> libtool-2.4 has lots of icky code to handle path transformations between
> various $build->$host environments.
> $ info libtool 'File name conversion'
> 
> ...
>   libtool supports file name conversion in the following scenarios:
> 
> build platform     host platform      Notes
> ---------------------------------------------------------------------------
> MinGW (MSYS)       MinGW (Windows)  *note Native MinGW File Name
>                                     Conversion::

Just for this lists finalization on this issue, I am using a standard
MSYS/MinGW configuration.  We'll continue the conversion with
bug-libtool list.
http://lists.gnu.org/archive/html/bug-libtool/2011-11/msg00009.html

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] mingw compile wdk demo

[Xiaofan Chen <xiaofanc@gm...>]

On Sun, Nov 6, 2011 at 9:50 PM, aj3423 <aj3423@...> wrote:
> I'm writing an ndis driver on win7 platform, using mingw.
> There're ddk header files but no helloworld examples.

Why do you want to develop drivers using MinGW? The
standard is WDK which is free download.

Moreover, MinGW.org does not provide 64bit compiler,
for driver development, you need to have 64bit compiler
since 64bit Windows needs 64bit driver.


-- 
Xiaofan

Re: [Mingw-users] gcc-4.6.1 no specs file delivered

[Keith Marshall <keithmarshall@us...>]

On 8 November 2011 02:02, Cesar Strauss wrote:
> On 11/07/2011 01:01 PM, Earnie wrote:
>
>> Has the procedure to deliver a specs file by default changed upstream or
>> is this a MinGW issue?
>
> GCC 3.4.5 has the specs file, but it's gone already in 4.2.1.

IIRC, upstream discontinued shipping of an external specs file for ALL
4.x releases, favouring built-in specs instead.

> In 4.6.1, at least, no such file is produced during make install.

As Ralph has already noted, if you need customised specs, you must first
run 'gcc -dumpspecs > specs' to create an external specs file.  Once it
has been created, and placed (for an MSYS hosted mingw32-gcc) at

  /mingw/lib/gcc/mingw32/$GCC_VERSION/specs

then GCC will use it instead of its built-in specs.

-- 
Regards,
Keith.

Re: [Mingw-users] gcc-4.6.1 no specs file delivered

[Ralph Engels <ralphengels@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noticed that its missing in gcc 4.1.2 and up but you can still print
it out by doing gcc -dumpspecs >> specfile. If you need it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOuQjuAAoJEIjGvG7Y4HU8dTkH/jSKrT2A7dIxfykQVBfB59Q8
pxPh1ddYxtxdKOM0cdMRWpveaqKdTZfjd2BjSgCgfYzX7EyM6vccGPg982IjSGpb
IXHr5LEovfFJnJDgt1QRSTxROKWGWppR9s//SZco0wgGHw+/RrtCCjzx7UpBDxJn
Rp8+zXC6jFWD6HyX7rYQO4nEpaXihVlQ9aCRaR0MSBVQR5EroQSLNv0wJ7f3nGN3
m7eKIjB8YR61EiOsuwI7R6DlRYgpZa5BmNSZBnmJK8ph2jIzpveG26Vcedqh63/s
iDvpjuW2EFdzBDuo8Gg/CHN0WiOgbI/6yPJ86sbKFSpTXhxUT+D2GVi+uft4b64=
=1T1F
-----END PGP SIGNATURE-----

Re: [Mingw-users] gcc-4.6.1 no specs file delivered

[Cesar Strauss <cestrauss@gm...>]

On 11/07/2011 01:01 PM, Earnie wrote:

> Has the procedure to deliver a specs file by default changed upstream or
> is this a MinGW issue?

GCC 3.4.5 has the specs file, but it's gone already in 4.2.1.

In 4.6.1, at least, no such file is produced during make install.

Regards,

Cesar

Re: [Mingw-users] Default includes via specs-file (cleanest solution?)

[Cesar Strauss <cestrauss@gm...>]

On 11/07/2011 07:53 AM, Commander Sirow wrote:
> Thus I followed the wiki instructions:
>  * gcc -dumpspecs > C:/MinGW/msys/1.0/lib/gcc/mingw32/4.6.1/specs

Try moving the specs file to /mingw/lib/gcc/mingw32/4.6.1/specs.

Regards,

Cesar