Keith Marshall | 20 Jan 19:40 2014
Picon
Picon

Re: mingw-pkg vs mgwport

On 19/01/14 20:48, Sebastian Schuberth wrote:
> Would you mind sharing mingw-pkg, at least privately, with me so that I 
> can evaluate it against mgwport (which does not seem to be maintained 
> anymore) for building the packages at [1]?

Sure.  I've created a git repository here:
https://sourceforge.net/u/keithmarshall/mingw-pkg/ci/master/tree/

FYI, I manage this using Mercurial, (git's only mitigating feature,
AFAIAC, being that I can do this).  Hence, there's an .hgignore file,
but currently no .gitignore, and I've provided an hg plugin to track
patches -- somewhat kludgey ATM, but I intend to rework it to use
Mercurial Queues.  I won't write it myself, but I will be happy to
consider patches to add a similar git plugin.

FWIW, my $HOME/.mingw-pkgrc is attached.

--

-- 
Regards,
Keith.
# Initialisation preferences for mingw-pkg tool.

AUTHOR="Keith Marshall"
AUTHOR_EMAIL="keithmarshall <at> users.sourceforge.net"

host=${host-"mingw32"}
build=${build-"x86_64-pc-linux-gnu"}

(Continue reading)

Keith Marshall | 18 Dec 12:52 2013
Picon
Picon

Our GCC-4.8 is broken

Guys,

IMO, our release of gcc-4.8.1 has been an unmitigated disaster!  Broken
packages; bugs such as https://sourceforge.net/p/mingw/bugs/2108/

This doesn't do a lot for our credibility; (the more so, since it now
seems that Earnie is remaining silent regarding the issues).  We need a
high priority plan to fix this.

In the short term, I'm inclined to suggest rolling back to GCC-4.7, as
our default offering, and ripping all of the broken packages out of the
on-line catalogue.

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
Aaron Gray | 30 Nov 15:25 2013
Picon

Building bison-3.0.1 via Cygwin MinGW32 cross compilation

Hi,
 
Following :- 
 
 
I have built bison 3.0.1 with a few source mods and using Cygwin :-
 
    export lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
    export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
 
    export PATH="/c/MinGW/bin:${PATH}"
    ../../src/bison-3.0.1/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32
 
On running bison.exe I am getting an error message in a popup:-
 
   The procedure entry point _set_invalid_parameter_handler could not be
   located in the dynamic library C:\MinGW\msys\1.0\bin\bison.exe
 
Am I using the right procedure ?
 
Many thanks in advance,
 
Aaron
 
 
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Keith Marshall | 19 Oct 00:00 2013
Picon
Picon

__FORCEINLINE vs. _CRTALIAS

Earnie,

What is your rationale for defining both of these?  Apart from a
syntactic inconsistency in their definitions, (which should be
eliminated), the two appear to be strictly equivalent.

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
Keith Marshall | 18 Oct 07:11 2013
Picon
Picon

_tfinddata64_t

Guys,

While formulating the patch attached to issue #2106:
https://sourceforge.net/p/mingw/bugs/_discuss/thread/07cb5e66/60ea/2b4b/attachment/dirent-2106.patch

I've noticed, and corrected, anomalies in io.h, wchar.h, and tchar.h,
relating to a data type formerly identified as _wfinddata64_t.  MSDN
does not refer to this type; all indications suggest that it should be
__wfinddata64_t instead, and I've modified the headers accordingly.

In tchar.h, for the non-unicode case, I also see a reference to a
corresponding _finddata64_t; MSDN suggests that this too should have an
additional leading underscore, becoming __finddata64_t; (indeed, all of
our other headers do seem to refer to it as such).

Actually, MSDN doesn't seem to mention any mapping for:

  _tfinddata64_t --> __wfinddata64_t   (unicode case)
  _tfinddata64_t --> __finddata64_t    (non-unicode case)

and I'm having a hard time seeing what value they might have; (they do
not seem to be referred to, at any other point throught the WSL code).

So, should we also adjust the non-unicode case for _tfinddata_t, in
tchar.h, or should we just drop these altogether?

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
Keith Marshall | 14 Oct 23:10 2013
Picon
Picon

Specification of DLL interface version numbers

Guys,

This is prompted by the debacle of Earnie's latest GCC release, (which
is still riddled with improperly specified dependencies -- see ticket
#2107 [https://sourceforge.net/p/mingw/bugs/2107/], and the gmane
archive thread, from MinGW-Users, to which it refers:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/43204/focus=43210

The DLL interface version number, (e.g. the -2 in libmpc-2.dll), is
*not* some arbitrary number which can be pulled out of the air, and/or
manipulated at random; it is to be computed *explicitly* from the
libtool version, as /current - age/.  Particularly pertinent here are
the references to libmpc-1.0.1-*-mingw32-dll-{2,3,4}.tar, which I see in
mingw32-gcc4.xml.  Of these, libmpc-4.dll is clearly bogus, for there is
no such release.  It seems to me that libmpc-3.dll is equally bogus, in
spite of the existence of a release bearing that version number.
Examining the sources for libmpc-1.0.1-1, (which furnishes
libmpc-2.dll), and for libmpc-1.0.1-2, (which furnishes libmpc-3.dll), I
see the statement, (in both):

> This distribution is created from pristine source without patches.

Furthermore, a comparison of their respective source tarballs:

> $ sum mpc-1.0.1-*/*.tar.*
> 25042   610 mpc-1.0.1-1-mingw32/mpc-1.0.1.tar.gz
> 25042   610 mpc-1.0.1-2-mingw32/mpc-1.0.1.tar.gz

indicates that they are, in fact, identical; this is further affirmed in
the release notes for the latter:

> Differences between -1 and -2:
> None other than a packaging resolution. 

This being the case, it is 100% wrong to have incremented the interface
version number between these two releases; these are both libmpc-2.dll,
and libmpc-3.dll is completely bogus; it is to be hoped that we have not
irretrievable polluted the distribution namespace, with this bogus
release, which should never have seen the light of day.  (And please,
let's not pollute it further, with a bogus libmpc-4.dll).

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
Earnie Boyd | 13 Oct 18:21 2013
Picon
Picon

make-4.0 has been released

Cesar,

Can you (do you have time to) create a make-4.0 release for MSYS?

Thanks,
--

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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Keith Marshall | 6 Oct 22:15 2013
Picon
Picon

Re: [mingw:bugs] #2094 mingw-dist needs XML validation tools

[https://sourceforge.net/p/mingw/bugs/2094/ refers]

To improve validation of our XML catalogues, prior to publication, I've
created an XML Schema Definition Language (XSDL) specification, which we
may use to check the condition of the mingw-dist source inventory; I've
also found a public domain example of Xerces-C++ code, which I can
easily adapt to generate a problem report, such as may be seen in the
above referenced ticket.

I'm thinking that this should be integrated into the mingw-dist build
infrastructure, such that the publishable image cannot be generated
while validation errors persist in the XML source inventory.  Possible
drawbacks would be that you would all need to install the Xerces-C++
SDK, (I added a mingw32 build to the "contrib" package set, a week or so
ago), before you could run the test suite, which would become a
mandatory prerequisite for publishing catalogues, and that uncaught
errors introduced by others could block your own publication builds.

If that seems too draconian, a possible mitigation could be to require
the validation check for a default build, but I could also expose a
secondary make goal, which would bypass the check.

Thoughts?

Furthermore, would you each like to follow up on the errors reported, on
the ticket, in respect of your own catalogues, or should I just go ahead
and fix them?

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
Earnie Boyd | 3 Oct 23:47 2013
Picon
Picon

Versioned DLL craziness for mingw-get

While I'll agree with the idea what we have at the moment is a mess
and better still not fully workable.  First, to install a previous
version of a DLL we need the catalogue library packages named with the
DLL version number so that the user could install two differing DLL.
Currently the user can only install version and that wasn't the
intent.

Next we have the development libraries, a developer supporting two
varying projects may need to have two or more varying development
packages of to match the versioned library.  We currently don't have
anything to support that at all.  The upstream packages certainly do
not version the libraries archives.  What I mean is that when
libfoo.dll.a is created the named DLL is stored in this file so we can
only use the named DLL anyway.

Furthermore in trying to develop a method to deliver such versioned I
started with gettext and the most recent version of it contains DLL
that are internal use only; the libgettextlib and libgettextsrc
libraries are versioned after the package version and the library
archive files are delivered in the lib/ directory but there are no
matching header files for them.  I'm thinking that these two library
archive files should not have been delivered.  Also we have files
delivered in lib/gettext, share/gettext and share/aclocal that are
impossible to break into libgettextpo or libintl related.

I am able to name the files that should go to
libgettextpo-0.18.3.1-2-mingw32-dev and libintl-0.18.3.1-2-mingw32-dev
but that left out the lib/gettext, share/gettext and share/aclocal
files so I ended up with a gettext-0.18.3.1-2-mingw32-dev file anyway.
 I put the libgettextlib-0-18-3.dll and libgettextsrc-0.18.3.dll in
with the -bin file since they are not meant for development of other
packages.  I left libgettextsrc.a, libgettextsrc.dll.a libgettextlib.a
and libgettextsrc.dll.a out of delivery since I do not see these as
needing to be delivered.

I suppose I should rename libgettextpo.dll.a to libgettextpo-0.dll.a
and libintl.dll.a to libintl-8.dll.a but then that throws autoconf
into not finding the library files properly and causes issues for the
developer.  Given that the proper versioning isn't happening today to
allow for multiple distribution and given that the development
libraries should also be versioned to allow for delivery.  Also, given
that autoconf would not use the versioned libraries and that there
would be more man hours than anyone has to muster to change the
situation; how can we deliver a proper versioning library system with
mingw-get?  Every single DLL development library would need to
maintain versioning to be effect for multiple versions of that library
to be delivered.

So, even though I agree with the concept; I find in practice that it
is a near impossibility to deliver.  Yes we can rename the packages
for the versioned DLL but that leaves the development libraries not
being versioned and that makes the versioned DLL package name rather
benign in use.

There is one use for DLL versioning while the development libraries
remain with the current DLL and that is applications that require the
older DLL while the new DLL is being refactored in to the production
stream.  However, if this is the reason for breaking out the libraries
into single packages named for the DLL library they represent, there
isn't much reason for that either.  The libraries can still be
delivered in one package named after the primary package name.

I am needing further convincing that DLL versioning within the package
delivery system is worth the time and effort needed to do it.  If we
want to deliver the possibility of multiple dll with different
versions; we need some work in the catalogue to be able to do that.

--

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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
Earnie Boyd | 3 Oct 15:03 2013
Picon
Picon

Attaching a bug ticket in the commit message

FYI,

If the commit message has a ticket number attached in the MD style of
[#nnnn] the SF display of the history will tie the commit to the
ticket by resolution of the MD ticket number.  Look at my recent
commits in the 4.1-dev branch of the mingw-org-wsl repository for an
example.

--

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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
Earnie Boyd | 27 Sep 00:32 2013
Picon
Picon

Catalogue package naming

Now that I've started working with the mingw-dist catalogue system and
understanding some nuances and such I'm going to suggest something
that will help with affiliate package naming for the GUI.

What I'm thinking is a categorical package naming system.  Using
package foo as an example I'm thinking that we could have a
mingw32-current-foo package a mingw32-previous-foo package and a
mingw32-history-foo package.  The history package would contain all
the packages older than previous.  I am also thinking that we have
package names of mingw32-current-ancillary-foo, etc where the
mingw-current-foo would contain the primary binary files and the
ancillary package would contain the documentation and other
non-required files for the binary package.  By doing this we can
present the user with a better GUI presentation based on the affiliate
grouping.

Thoughts?

--

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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Gmane