gmane.comp.gnu.mingw.devel

bug 1855: libmudflap -- MinGW thread

arthur — 2013-05-03T20:16:32

To address bug 1855 [1], I try to add --enable-libmudflap to build gcc.

It failed as:

...
checking for thread model used by GCC... win32
win32 is an unsupported thread package
make[1]: *** [configure-target-libmudflap] Error 1
...

The direct cause from configure.ac:

...
# We only support posix threads, or no threads at all.
posix_threads=
case ${target_thread_file} in
   posix)
     posix_threads=yes
     ;;
   single)
     ;;
   *)
     echo "${target_thread_file} is an unsupported thread package" 1>&2
     exit 1
     ;;
esac
...

I believe MinGW has a POSIX interface for threading (pthreads-w32?). Is 
this true? If yes what is your suggestion on patching this. Adding 
'win32)\n posix_threads=yes' directly there looks ugly.

You have a good weekend!

[1] https://sourceforge.net/p/mingw/bugs/1855/

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down t

Fwd: Fwd: binutils 2.23.2-3

Earnie Boyd — 2013-04-29T16:36:33

---------- Forwarded message ----------
From: nick clifton <nickc-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Date: Mon, Apr 29, 2013 at 12:15 PM
Subject: Re: Fwd: binutils 2.23.2-3
To: Earnie Boyd <earnie-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org>, binutils-9JcytcrH/bA+uJoB2kUjGw< at >public.gmane.org


Hi Earnie,




Nope - just a snafu.  I have updated the websites.

Cheers
  Nick

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

John E. / TDM — 2013-04-25T23:35:22

I believe 2.23.2 has been officially released, but without its 
corresponding webpage update. See 
<http://sourceware.org/ml/binutils/2013-03/msg00279.html>.

-John E. / TDM

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

arthur — 2013-04-25T21:30:25

Just reminder: binutils 2.23.2 is not released yet even it is on ftp, 
but not on the home page.

http://www.gnu.org/software/binutils/


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

arthur — 2013-04-25T21:27:56

You are part of this. Thank you again for the building hint and 
suggesting those options.


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

Earnie Boyd — 2013-04-25T13:19:21

So the next steps are to get the changes to the mingw-dist
repository[1] correct.

[1] https://sourceforge.net/p/mingw/mingw-dist/ci/master/tree/

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

John E. / TDM — 2013-04-25T01:01:41

 From my limited use in compiling a few test programs, it seems to be an 
eminently usable replacement for the previous release. Congratulations 
on completing a GCC/MinGW bootstrap!

-John E. / TDM

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Please test: gcc 4.8.0-1 and binutils 2.23.2-3

arthur — 2013-04-24T17:38:35

Both build with i686-pc-mingw32.

Individual packages are under the folders of:

https://sourceforge.net/projects/arthurzhang.u/files/mingw/


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: gcc4.8.0 build and package

Earnie Boyd — 2013-04-23T22:35:00

I don't see the point.  They're actually used for cross compiling so
let the i686-pc-mingw32-*.exe replace them.  The mingw-get process
should remove the mingw32-*.exe IIRC when the upgrade occurs.

Re: gcc4.8.0 build and package

arthur — 2013-04-23T21:27:43

....


I just notice that those bin\mingw32-*.exe are wrapper executables so I 
think even the gcc install will install bin\i686-pc-mingw32-*.exe then 
we still can mv them as bin\mingw32-*.exe (after overwritten as wrapper 
exes).

Do you want we keep as bin\mingw32-*.exe (as today) or keep as 
bin\i686-pc-mingw32-*.exe (as gcc 4.8.0 installed).


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: gcc4.8.0 build and package

Earnie Boyd — 2013-04-23T12:17:09

The contents of the ticket make your question understandable.  Use
--build=i686-pc-mingw32 and we will leave those using anything less
behind as far as pre-build options go.  We can help them get the
source built for their own use on the mingw-users list.  You will need
to call this out in the announcement and the MINGW-README file.  Give
the bug ticket as your reasoning for the change.

Re: gcc4.8.0 build and package

arthur — 2013-04-22T21:38:08

Thanks for this info. I will rebuild binutils with the new configure first.


Yes:-)


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Re: gcc4.8.0 build and package

arthur — 2013-04-22T21:33:55

Got it.


Changes in gcc 4.8.0 introduce multiple undefined references for Ada. 
See this ticket:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Re: gcc4.8.0 build and package

John E. / TDM — 2013-04-22T19:45:55

GNU binutils will need to be rebuilt with the same target spec, 
otherwise it will break full "relocatability" due to GCC looking in 
<sysroot>/<target>/bin for binutils executables.


I believe Arthur is presenting this 3rd option as an alternative to 
changing the target architecture.

-John E. / TDM

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Re: gcc4.8.0 build and package (was: gcc 4.8.0 Adaerror)

Earnie Boyd — 2013-04-22T18:05:03

I think the common platform in today's world is i686 and perhaps worth
the change at this time. It is time we started using the full triplet
directory because of x86_64 which we will eventually be able to
distribute.  The users will need to know the difference.


It shouldn't break anything.  It will cause user confusion. The
mingw-get installer should handle the removal of the old structure to
present the new structure to the user.


Why does Ada not build?

Re: gcc4.8.0 build and package (was: gcc 4.8.0 Ada error)

arthur — 2013-04-22T16:40:24

Hi All, I need your input with regarding the direction of building and 
packaging gcc 4.8.0.

You can find some more discussions from 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909

Please let me know which option you'd like to go, or you may have other 
suggestion. Thanks.

1. build with '--with-arch=i686 --build=mingw32'
   this will force arch to i686 ONLY

2. build with '--build=i686-pc-mingw32'

   this is the suggested workaround by gcc team, however, our old v4.7.2 
has lib installed to \MinGW\lib\gcc\mingw32\4.7.2 (as --build=mingw32)
but now new v4.8.0 build will install lib to 
...\gcc\i686-pc-mingw32\4.8.0. This also applies to libexec dir too. 
Also the bin\mingw32-*.exe will become bin\i686-pc-mingw32-*.exe

As my limited tests, gcc looks fine with above dir/file name changes but 
I don't know if this may break other (e.g. MSYS) part of MinGW.

3. exclude Ada from v4.8.0 build and package

   this leaves our Ada package as 4.7.2



------------------------------------------------------------

Re: Improving the performance of "mingw-get update"

waterlan — 2013-04-22T07:36:43

Keith Marshall schreef op 2013-04-22 00:29:

Okay.


Fine.

regards,

Re: Improving the performance of "mingw-get update"

Keith Marshall — 2013-04-21T22:35:38

Done.  The modified infrastructure is in place; will all of you with 
active sandboxes please pull the changes, re-run autoconf, and then 
reconfigure your working copies, before making any further changes.


Regardless, I now think it prudent to reissue the package lists, with 
updated issue stamps in any case, so I've gone ahead and done so.

Re: Improving the performance of "mingw-get update"

Keith Marshall — 2013-04-21T22:29:22

I've done that now.  FWIW, I've also corrected the file attributes for 
your previous commits, Erwin -- XML and log files should not have the 
executable bits set.  Please investigate why they did, and rectify that 
anomaly on the next occasion when you commit.


I prefer 'contrib', which is what I've used; the catalogues don't live 
in 'Contributed' on FRS anyway, so there's no particular reason to use 
this name, (and I dislike mixed case directory names in general).

Re: Improving the performance of "mingw-get update"

Erwin Waterlander — 2013-04-19T19:35:01

Keith Marshall schreef, Op 17-4-2013 14:18:

Hi,

I think it's a good idea to have the XMLs in a contrib folder in 
mingw-dist. Or name the folder "Contributed" in line with the name in 
MinGW Files.

regards,

Re: Improving the performance of "mingw-get update"

Keith Marshall — 2013-04-17T12:18:39

Okay, but I do have a couple of comments of my own:

1) Both ChangeLog and my newly generated mingw32-package-list.xml.lzma 
(attached) indicate that you, Earnie, added mingw32-wsl-candidate.xml on 
2013-04-10, but the package list itself bears an earlier time stamp, 
indicating a last update for publication on 2013-03-05.  Although this 
looks incongruous, it is possible if you added the *reference* for the 
XML file to the package list, and rebuilt as "publication ready" on this 
date, more than a month before you actually made the XML file itself 
available for publication; however, is it correct?

2) The two packages in the "user contributed" category, (both Erwin's 
IIRC), aren't qualified with a publication date stamp in the generated 
package list; this arises because neither of the associated XML files is 
physically present within the mingw-dist repository.  This isn't 
necessarily a problem -- mingw-get will simply continue to behave as it 
does now, WRT these two files, and download them every ti