Re: [Mingw-users] Quoted wildcards in arguments to MinGW programs and bug 3482704

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

On 10/05/12 21:35, Eli Zaretskii wrote:
> '?' and '*' cannot appear in Windows file names,

True, but you may wish to use GLOB_NOCHECK to push a literal `*' or `?'
into a glob_t.gl_pathv vector; if we don't have an escaping mechanism,
then those tokens are always going to be globbed when any match exists,
which surely isn't what you want.

> so the only issue is with '['.  And a literal '[' can be "escaped" by
> using [[].

And similarly, `[*]' and `[?]'; slightly awkward perhaps, but maybe this
really is the best solution.  The disadvantage is that those literal
trigraphs, `[*]', `[?]', and/or `[[]' will be copied verbatim into the
GLOB_NOCHECKed glob_t.gl_pathv result, but any alternative could be
equally undesirable.

> So this should let us have GLOB_NOESCAPE be a no-op.

Which it is, at present.  If it's to stay this way, then

  #define GLOB_NOESCAPE  0

seems appropriate, in glob.h

> We could also use '^', but I personally don't see a compelling
> reason.  Am I missing something?

I'm not sure; hence the discussion.  I'm not seeing anything especially
compelling either.  Thanks.

-- 
Regards,
Keith.

Re: [Mingw-users] Quoted wildcards in arguments to MinGW programs and bug 3482704 (Unicode)

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

On 10/05/12 08:36, waterlan wrote:
> How about globbing when there are files with Unicode characters?

The current implementation supports only ASCII file names.  It had
occurred to me that a further UTF-16LE implementation may be desirable,
but that will be for "later".

> The normal MSVCRT.DLL globbing doesn't work. You get a question mark 
> for the Unicode characters, and when your program tries to open the file 
> you get 'file not found'.

Sure.  You need a UTF-16LE implementation to support UTF-16LE file
names.  However, the existing MinGW start-up code supports only the
ASCII name space, and my present focus is on replacing that.

> So what I do to read Unicode arguments is this:
> 
>      wchar_t *cmdstr;
>      wchar_t **wargv;
> 
>      cmdstr = GetCommandLineW();
>      wargv = CommandLineToArgvW(cmdstr, &argc);
> 
> Actually I don't know if this does any globbing.

I don't either.  I suspect not, since there's no selector to enable it,
as there would be if you used __wgetmainargs() instead.  However, if you
were to make that change, I would expect similarly broken globbing to
that exhibited by __getmainargs(), in the ASCII case; the primary
purpose of this effort is to fix that, while also adding a few more
POSIX-like enhancements as a secondary (optional) benefit.

> Perhaps it would be handy if you add another glob function that 
> automatically returns all file names (including Unicode names) in UTF-8 

UTF-8?  What's that?  Okay, I do know, really; just couldn't resist a
dig at the blatantly misinformed brainwashing Microsoft subject their
users to, when they attempt to convince us that

   Unicode == UTF-16LE

(as if UTF-32, UTF-32LE, UTF-32BE, UTF-16, UTF-16BE, and UTF-8 either
don't exist at all, or somehow, don't qualify as Unicode formats).

> instead of ANSI code. This is then still ASCII compatible, and if your 
> program needs to support Unicode on Windows the program can convert the 
> UTF-8 arguments to wide characters.

When I have the glob(3) implementation working to my satisfaction, I may
consider adapting it to provide a UTF-16LE based _wglob() variant; I
have no plans for a UTF-8 specific variant.  (Actually, there's no
particular reason why the present version wouldn't work with UTF-8, as
is; the limitation would stem from the capability of _findfirst() and
_findnext(), as used by opendir(3) and readdir(3) in libmingwex.a's
dirent implementation, to return file names which include non-ASCII
8-bit characters).

-- 
Regards,
Keith.

Re: [Mingw-users] Quoted wildcards in arguments to MinGW programs and bug 3482704

[Eli Zaretskii <eliz@gn...>]

> Date: Thu, 10 May 2012 20:29:45 +0100
> From: Keith Marshall <keithmarshall@...>
> 
> The issue I intended to raise was not the escaping of quotes, but of
> globbing tokens.  In any POSIX conforming glob(3) implementation, if
> GLOB_NOESCAPE is not set in the flags argument, any \ in the pattern
> will be parsed as an escape, so *, ?, and [, in \*, \?, and \[, lose
> their significance as globbing tokens.  In a Windows implementation that
> becomes problematic, because \ is normally read as a directory name
> separator, which would make
> 
>   $ glob c:\foo\bar\*.*
> 
> ambiguous, and I don't think we can realistically expect users to adapt
> to consistently using
> 
>   $ glob c:\foo\bar\\*.*
> 
> as an unambiguous alternative.  So, if we want GLOB_NOESCAPE to have any
> significance at all, (and I think it should), then we need to choose an
> alternative escape character, for use within the glob(3) implementation
> on which this improved command line globbing method  depends.  What
> character should we choose?  ^ perhaps?  Or should we expect cmd.exe to
> swallow that?  Some other choice?  I'm open to suggestions.

'?' and '*' cannot appear in Windows file names, so the only issue is
with '['.  And a literal '[' can be "escaped" by using [[].  So this
should let us have GLOB_NOESCAPE be a no-op.

We could also use '^', but I personally don't see a compelling
reason.  Am I missing something?

Re: [Mingw-users] Quoted wildcards in arguments to MinGW programs and bug 3482704

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

On 10/05/12 06:22, Eli Zaretskii wrote:
>> Date: Wed, 09 May 2012 22:37:37 +0100
>> From: Keith Marshall
>>
>> I've posted a new mingwrt snapshot at http://tinyurl.com/cgkckca
> 
> Thank you!
> 
>> The new glob(3) function is mostly POSIX compliant, (but currently
>> doesn't implement any use of the (*errfn)() argument).  It *does* add
>> globbing of character groups, such as [abc] and [!xyz], which may not be
>> familiar to Windows users; we may want to consider making this a
>> non-default optional feature
> 
> Yes, it should probably be optional.

Easily accommodated, (for the command line parse only; the glob(3)
function itself will continue to support it unconditionally).  Add 0x20
to _CRT_glob, (as boolean addition; it needs ((_CRT_glob & 2) == 2) to
select the new glob(3) algorithm, and other options are then bit
mapped), to enable it for the command line.

New snapshot, posted at same URL, implements this, together with
tentative handling for the (*errfn)() hook.

>> One additional feature, which I have made a non-default option; with the
>> new globbing algorithm, adding 0x10 to _CRT_glob, as in:--
>>
>>    int _CRT_glob = 0x12;
>>
>> and you'll get POSIX-like handling of *both* apostrophes *and* double
>> quotes, as argument quoting characters.  However, \ remains as a
>> directory name separator, so isn't available as an escape; we may need
>> to choose a new alternative character for use as an escape, as a later
>> addition.  Thoughts?  Suggestions?
> 
> Treat \ as an escape character only if it precedes a ' or " character.

Sorry.  I didn't express this clearly.  You've answered the question I
posed, but (unsurprisingly) not the one I intended.

> That's what DJGPP does, and it works very well in practice.

Yeah.  That's also what Microsoft stipulates, (at least in the case of
the double quote; see http://tinyurl.com/6vgvax8).  Extending that to
handle escaped apostrophes similarly, (when the `apostrophes as quotes'
option is enabled), is a no-brainer; if I've got it right, (as I think I
have), my implementation should already work this way.

The issue I intended to raise was not the escaping of quotes, but of
globbing tokens.  In any POSIX conforming glob(3) implementation, if
GLOB_NOESCAPE is not set in the flags argument, any \ in the pattern
will be parsed as an escape, so *, ?, and [, in \*, \?, and \[, lose
their significance as globbing tokens.  In a Windows implementation that
becomes problematic, because \ is normally read as a directory name
separator, which would make

  $ glob c:\foo\bar\*.*

ambiguous, and I don't think we can realistically expect users to adapt
to consistently using

  $ glob c:\foo\bar\\*.*

as an unambiguous alternative.  So, if we want GLOB_NOESCAPE to have any
significance at all, (and I think it should), then we need to choose an
alternative escape character, for use within the glob(3) implementation
on which this improved command line globbing method  depends.  What
character should we choose?  ^ perhaps?  Or should we expect cmd.exe to
swallow that?  Some other choice?  I'm open to suggestions.

>> I'd like to tidy up some loose ends, before this is released, but please
>> feel free to play with the snapshot, and report any issues.
> 
> Will do, definitely.
> 
> Thanks again for doing this.

You're welcome.

-- 
Regards,
Keith.

Re: [Mingw-users] remove from list

[Tuomo Latto <djv@ik...>]

On 10.05.2012 14:19, Graham, Albert B. (LARC-D501)[Jacobs Technology, Inc.] wrote:
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...?subject=unsubscribe

Please read the above blurb found at the end of all list messages.
It's not rocket science.


-- 
Tuomo

... Why are you looking down here? The joke is above!

Re: [Mingw-users] [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely <jwakely.gcc@gm...>]

On 10 May 2012 15:03, K. Frank wrote:
>
> Neither of these shows --enable-threads of any flavor (in gcc -v), but both
> show "Thread model: win32" in the gcc -v output.

Yep, if you don't explicitly configure with --enable-threads then the
configure script picks a suitable default, which is "win32" on
Windows.


>> If you use GCC built with --enable-threads=posix then you shouldn't
>> need to implement <thread>, it should be provided.
>
> No, this is not strictly true.  Prior to Kai's winpthread implementation
> and Ruben's <thread>-enabled build (or the tweaks I made to get
> <thread> working), building a windows version of gcc with
> --enable-threads=posix won't, in and of itself, give you a working
> <thread>.  One reason, among others, is that the posix version of
> gcc's <thread> relies on the pthreads thread handle being a primitive
> integral type.  This is not required by the posix standard, but is how
> unix / linux pthreads has historically been implemented.  However,
> pthreads-w32 uses (a pointer to) a struct as its thread handle,

Yes, I don't think we have an open bugzilla report about that
portability problem, but it's a known issue.

> So you either need a little tweak to accommodate this handle
> difference, or follow Kai's approach of providing a windows version
> of pthreads that uses an integral thread handle (winpthreads).

Have those changes come back upstream? It sounds as though they should do.


>> The code is all open source, feel free to read it.
>
> Yes, of course, as a last resort.  But it's generally not my first choice.
> (By way of analogy, I find it more practical to read the c++11 standard
> for <thread>, or ask questions in the c++ news group, rather than read
> the gcc source code for <thread>.)

That makes sense for <thread> because the standard is the
authoritative source.  For GCC's configuration the GCC sources are the
authoritative source :-)

Sorry if my last mail seemed impatient, I do appreciate your feedback
based on your own experience of implementing <thread>.

Re: [Mingw-users] [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[K. Frank <kfrank29.c@gm...>]

Hello Jonathan!

On Wed, May 9, 2012 at 7:06 PM, Jonathan Wakely <jwakely.gcc@...> wrote:
> On 9 May 2012 20:06, K. Frank wrote:
>> However, as noted in my previous post, I have happily done some
>> (limited) windows-api threading programming with Ruben's build
>> (and also did the windows-api threading programming necessary
>> to implement <thread>),

That's my fault for the confusion; I misspoke.

The --enable-threads=posix build of Ruben's that I referenced:

   gcc version 4.7.0 20110829 (experimental) (GCC)

is Ruben's <thread>-enabled 4.7.0 mingw-w64 build.

This is not the build upon which I built my threading implementation.

Instead I built my thread implementations on the following two
builds:

   a mingw build:
   gcc version 4.5.0 (GCC)

and

   a mingw-w64 build:
   gcc version 4.5.2 20101002 (prerelease) [svn/rev.164902 - mingw-w64/oz] (GCC)
   (If I remember correctly, this is a "sezero" build.)

Neither of these shows --enable-threads of any flavor (in gcc -v), but both
show "Thread model: win32" in the gcc -v output.

Sorry for the confusion.

On top of both of these builds I implemented my native win32-based
<thread>.  Note, in spite of "Thread model: win32" showing up in
gcc -v, I'm pretty sure that _GLIBCXX_HAS_GTHREADS was not
defined when these builds were built.

Separately I tweaked both of these builds to get <thread> working
by hooking them up to pthreads-w32 and pthreads-w64, respectively.
(Note, pthreads-w64 is not the winpthreads implementation that
Kai provided later, and is used by Ruben's <thread>-enabled build.
Rather, I would guess it's a tweak of pthreads-w32 built for 64-bit
windows.)

> If you use GCC built with --enable-threads=posix then you shouldn't
> need to implement <thread>, it should be provided.

No, this is not strictly true.  Prior to Kai's winpthread implementation
and Ruben's <thread>-enabled build (or the tweaks I made to get
<thread> working), building a windows version of gcc with
--enable-threads=posix won't, in and of itself, give you a working
<thread>.  One reason, among others, is that the posix version of
gcc's <thread> relies on the pthreads thread handle being a primitive
integral type.  This is not required by the posix standard, but is how
unix / linux pthreads has historically been implemented.  However,
pthreads-w32 uses (a pointer to) a struct as its thread handle,

So you either need a little tweak to accommodate this handle
difference, or follow Kai's approach of providing a windows version
of pthreads that uses an integral thread handle (winpthreads).

> In any case, as you're not using the win32 thread model you shouldn't
> are about my proposals and you're just derailing the topic ;-)

Sorry, that wasn't my intent.

I had thought you were discussing two parallel proposals:  First,
adding additional functionality and some support for <thread> to
the win32 implementation (gthr-win32.h, etc.); and second to
consider building a new, native (non gthr-win32.h, non gthr-posix.h)
<thread> implementation for gcc's <thread> on windows.

My main purpose was to share my experience doing the latter,
but I did make some comments about possible limitations of
doing the former.

I apologize if I may have confused the discussion by not being
familiar with the gcc's community use of "win32" in the term "win32
threading model."  In the windows world "win32" generally has the
connotation of the native windows api, and it didn't ring a bell with
me that it might refer to a windows-focused (partial) implementation
of the "gthreads" threading api (as in "_GLIBCXX_HAS_GTHREADS",
etc.).

>> all, I guess, with a gcc build built using
>> --enable-threads=posix, so what then does --enable-threads=win32
>> actually do?
>
> The code is all open source, feel free to read it.

Yes, of course, as a last resort.  But it's generally not my first choice.
(By way of analogy, I find it more practical to read the c++11 standard
for <thread>, or ask questions in the c++ news group, rather than read
the gcc source code for <thread>.)

> --enable-threads=win32 tells GCC to use the gthr-win32.h header to
> implement the gthreads abstraction API.  Gthreads provides a
> pthreads-like API which libstdc++ (and libobjc and other bits of GCC)
> use for threading facilities.  WIth --enable-threads=posix GCC uses
> the gthr-posix.h file which provides an implementation of gthreads
> based on pthreads (which is a one-to-one mapping.) With
> --enable-threads=win32 GCC uses the gthr-win32.h file which provides
> an implementation based on Windows primitives, which as I said several
> days ago means that the __gthread_mutex_t type is implemented as
> semaphores.

Yes, thank you.  This is coming back to me now, and I'm now clear on
what --enable-threads=win32 means and does.

> ...
> My original email, which I now seem to be repeating over and over,
> suggests changes to gthr-win32.h to allow std::mutex and C++11 other
> types to be defined in terms of the Windows primitives currently used
> in gthr-win32.h
>
> That gthr-win32.h header already exists, and already defines
> __gthread_mutex_t in terms of a semaphore, and it's too late to change
> that.  So maybe if you re-read my original mail now it will make more
> sense.

Yes, thank you.  I follow what you're saying now and how gthr-win32.h
fits into everything.

In fact, in my native <thread> implementation I modified neither
gthr-win32.h nor gthr-posix.h, but wrote a new gthr-expr.h (and
some associated helper code).

> I proposed extending gthr-win32.h to allow std::thread and
> std::mutex to be provided WITHOUT CHANGING THE EXISTING IMPLEMENTATION
> OF gthr-win32.h, which would not allow native condition variables to
> be used because std::mutex is based on a semaphore and changing
> gthr-win32.h to not use a semaphore would not be backwards compatible
> and so is not an option.

Yes, of course.  If folks are using gthr-win32.h, we shouldn't break it
for them.

> In order to solve that problem I proposed a completely new gthreads
> implementation, for argument's sake gthr-win64.h, which being
> completely new could implement std::mutex differently, e.g. as a
> critical section, and std::condition_variable as a Windows condition
> variable,

Yes, this is what I did with my native "gthr-expr.h" <thread> implementation.

> As you are using gthr-posix.h you shouldn't need to care, you should
> already have std::mutex, std::thread, std::condition_variable etc.

Yes, now that Ruben has provided <thread>-enabled build (that indeed
was built with --enable-threads=posix), I do have std::thread, etc.
And this is the version of gcc I use for my day-to-day work.

But prior to Ruben's build (or when I want to play around with a native,
rather than a pthreads-based implementation) I used my own patched
version of one of Ozkan's builds (and also a 32-bit mingw build) to do
my windows <thread> programming, as that was my only option.

>
> So now I hope everyone's on the same page, but I don't actually think
> this thread has anything new since my original email on this subject
> four days ago  :-\

Yes, thank you very much.


K. Frank

[Mingw-users] remove from list

[Graham, Albert B. (LARC-D501)[Jacobs Technology, Inc.] <albert.b.graham@na...>]

Re: [Mingw-users] CreateProcess No such file or directory

[Gert Martin <fjvumr@ho...>]

do you attach something so that you do not send to use list
 



From: sfhacker@...
To: fjvumr@...
Subject: [Mingw-users] CreateProcess No such file or directory
Date: Thu, 10 May 2012 07:20:11 +0100




> any one success to compile LAPACK 3.1.1 or 3.4.1 in window 7 64 bit with mingw32-gfortran

Hi there,

I sent you an email last month. Did you receive it?
 		 	   		  

Re: [Mingw-users] Quoted wildcards in arguments to MinGW programs and bug 3482704 (Unicode)

[waterlan <waterlan@xs...>]

Keith Marshall schreef op 2012-05-09 23:37:

> I've posted a new mingwrt snapshot at http://tinyurl.com/cgkckca
>
> It extends the meaning of global variable _CRT_glob, (which you may
> define in one of your source files, to override the default), as
> follows:--
>
> int _CRT_glob = 0; // no globbing; same as current release
> int _CRT_glob = 1; // MSVCRT.DLL globbing; same as current
> int _CRT_glob = 2; // new libmingwex.a glob(3) function
>
> (2 is default, for this snapshot).
>
> The new glob(3) function is mostly POSIX compliant, (but currently
> doesn't implement any use of the (*errfn)() argument). It *does* add
> globbing of character groups, such as [abc] and [!xyz], which may not 
> be
> familiar to Windows users; we may want to consider making this a
> non-default optional feature, but it's currently always available, 
> when
> using the new globbing algorithm.
>
> One additional feature, which I have made a non-default option; with 
> the
> new globbing algorithm, adding 0x10 to _CRT_glob, as in:--
>
> int _CRT_glob = 0x12;
>
> and you'll get POSIX-like handling of *both* apostophes *and* double
> quotes, as argument quoting characters. However, remains as a
> directory name separator, so isn't available as an escape; we may 
> need
> to choose a new alternative character for use as an escape, as a 
> later
> addition. Thoughts? Suggestions?
>
> I'd like to tidy up some loose ends, before this is released, but 
> please
> feel free to play with the snapshot, and report any issues.
>

Hi,

How about globbing when there are files with Unicode characters?

The normal MSVCRT.DLL globbing doesn't work. You get a question mark 
for the Unicode characters, and when your program tries to open the file 
you get 'file not found'.

So what I do to read Unicode arguments is this:

     wchar_t *cmdstr;
     wchar_t **wargv;

     cmdstr = GetCommandLineW();
     wargv = CommandLineToArgvW(cmdstr, &argc);

Actually I don't know if this does any globbing.

Perhaps it would be handy if you add another glob function that 
automatically returns all file names (including Unicode names) in UTF-8 
instead of ANSI code. This is then still ASCII compatible, and if your 
program needs to support Unicode on Windows the program can convert the 
UTF-8 arguments to wide characters.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

Re: [Mingw-users] build ld.exe from sources

[Paul S. <paulshtukov@gm...>]

Thank you

On 10 May 2012 08:18, Teemu Nätkinniemi <stinkf42@...> wrote:
> On 10.5.2012 4:02, Paul S. wrote:
>
>> Where can i find sources of "ld.exe" from  mingw binutils?
>
> Here you go. Download binutils-2.22-1-mingw32-src.tar.lzma
>
> http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.22/
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...?subject=unsubscribe

Re: [Mingw-users] Quoted wildcards in arguments to MinGW programs and bug 3482704

[Eli Zaretskii <eliz@gn...>]

> Date: Wed, 09 May 2012 22:37:37 +0100
> From: Keith Marshall <keithmarshall@...>
> 
> I've posted a new mingwrt snapshot at http://tinyurl.com/cgkckca

Thank you!

> The new glob(3) function is mostly POSIX compliant, (but currently
> doesn't implement any use of the (*errfn)() argument).  It *does* add
> globbing of character groups, such as [abc] and [!xyz], which may not be
> familiar to Windows users; we may want to consider making this a
> non-default optional feature

Yes, it should probably be optional.

> One additional feature, which I have made a non-default option; with the
> new globbing algorithm, adding 0x10 to _CRT_glob, as in:--
> 
>    int _CRT_glob = 0x12;
> 
> and you'll get POSIX-like handling of *both* apostophes *and* double
> quotes, as argument quoting characters.  However, \ remains as a
> directory name separator, so isn't available as an escape; we may need
> to choose a new alternative character for use as an escape, as a later
> addition.  Thoughts?  Suggestions?

Treat \ as an escape character only if it precedes a ' or " character.
That's what DJGPP does, and it works very well in practice.

> I'd like to tidy up some loose ends, before this is released, but please
> feel free to play with the snapshot, and report any issues.

Will do, definitely.

Thanks again for doing this.

Re: [Mingw-users] build ld.exe from sources

[Teemu Nätkinniemi <stinkf42@ya...>]

On 10.5.2012 4:02, Paul S. wrote:

> Where can i find sources of "ld.exe" from  mingw binutils?

Here you go. Download binutils-2.22-1-mingw32-src.tar.lzma

http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.22/

Re: [Mingw-users] CreateProcess No such file or directory

[Gert Martin <fjvumr@ho...>]

Hi all,
 
any one success to compile LAPACK 3.1.1 or 3.4.1 in window 7 64 bit with mingw32-gfortran

Regards,
Martin
 



From: fjvumr@...
To: mingw-users@...
Date: Sat, 28 Apr 2012 18:14:51 +0800
Subject: Re: [Mingw-users] CreateProcess No such file or directory




Hi sir,

After tried mingw32-gfortran,

cc7Dhzva.o C:\Users\MARHIL~1\AppData\Local\Temp\ccmaefqO.o C:\Users\MARHIL~1\App
Data\Local\Temp\ccNcsXuF.o C:\Users\MARHIL~1\AppData\Local\Temp\ccoEGaqI.o C:\Us
ers\MARHIL~1\AppData\Local\Temp\ccGtGbbL.o C:\Users\MARHIL~1\AppData\Local\Temp\
ccwutHs1.o C:\Users\MARHIL~1\AppData\Local\Temp\ccso57wt.o C:\Users\MARHIL~1\App
Data\Local\Temp\ccYgVin7.o C:\Users\MARHIL~1\AppData\Local\Temp\ccCneMuW.o C:\Us
ers\MARHIL~1\AppData\Local\Temp\ccQiSLZT.o C:\Users\MARHIL~1\AppData\Local\Temp\
ccxAk1uV.o C:\Users\MARHIL~1\AppData\Local\Temp\ccicyMI8.o C:\Users\MARHIL~1\App
Data\Local\Temp\ccLg5lay.o C:\Users\MARHIL~1\AppData\Local\Temp\ccaZdWD8.o C:\Us
ers\MARHIL~1\AppData\Local\Temp\ccNiIjXR.o C:\Users\MARHIL~1\AppData\Local\Temp\
ccknyRwM.o blas.dll -lgfortran -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lms
vcrt -lquadmath -lm -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladva
pi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex
-lmsvcrt d:/mingw/bin/../lib/gcc/mingw32/4.6.2/crtend.o

mingw32-gfortran: error：CreateProcess: No such file or directory

Regards,
Martin



> Date: Thu, 12 Apr 2012 00:09:05 +0800
> From: xunxun1982@...
> To: mingw-users@...
> Subject: Re: [Mingw-users] CreateProcess No such file or directory
> 
> Try to replace gfortran with mingw32-gfortran
> 
> 2012/4/10 Gert Martin <fjvumr@...>:
> >
> > Hi sir,
> >
> > After installed MingG, compiled and output blas.dll is successful with
> > gfortran,
> > run the following command, meet error
> >
> > D:\April2012\lapack-3.4.0>gfortran -shared -o lapack.dll SRC\*.f blas.dll -O
> > gfortran: error：CreateProcess: No such file or directory
> >
> > Regards,
> >
> > Martin
> >
> >
> > ------------------------------------------------------------------------------
> > Better than sec? Nothing is better than sec when it comes to
> > monitoring Big Data applications. Try Boundary one-second
> > resolution app monitoring today. Free.
> > http://p.sf.net/sfu/Boundary-dev2dev
> > _______________________________________________
> > MinGW-users mailing list
> > MinGW-users@...
> >
> > This list observes the Etiquette found at
> > http://www.mingw.org/Mailing_Lists.
> > We ask that you be polite and do the same.  Disregard for the list etiquette
> > may cause your account to be moderated.
> >
> > _______________________________________________
> > You may change your MinGW Account Options or unsubscribe at:
> > https://lists.sourceforge.net/lists/listinfo/mingw-users
> > Also: mailto:mingw-users-request@...?subject=unsubscribe
> 
> 
> 
> -- 
> Best Regards,
> xunxun
> 
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second 
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
> 
> This list observes the Etiquette found at 
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
> 
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...?subject=unsubscribe

------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:mingw-users-request@...?subject=unsubscribe 		 	   		  

[Mingw-users] build ld.exe from sources

[Paul S. <paulshtukov@gm...>]

Hello

Where can i find sources of "ld.exe" from  mingw binutils?

Paul

Re: [Mingw-users] [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Gabriel Dos Reis <gdr@in...>]

On Wed, May 9, 2012 at 6:14 PM, Jonathan Wakely <jwakely.gcc@...> wrote:
> On 9 May 2012 20:49, Kai Tietz wrote:
>>
>> The issue about critical-sections and gthread (and also pthread) API
>> is, that not all locking-kinds can be modelled by it.  The difference
>> on Windows for it is, that a critical section object provides
>> synchronization similar to that provided by a mutex object, except
>> that a critical section can be used *only* by the threads of a single
>> process.
>> (see  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682530%28v=vs.85%29.aspx
>> ).  This makes it pretty useless for many classical scenarios.
>
> Since the C++ standard doesn't say anything about IPC, std::mutex only
> needs to work for a single process, so that's not necessarily a
> problem.  Also, libstdc++ on POSIX uses a pthread_mutex_t that isn't
> necessarily safe for use in multiple processes, as it doesn't have the
> PTHREAD_PROCESS_SHARED attribute set (unless the OS sets it by default
> for all mutexes).
>
> It could be argued that a different type (let's call it
> interprocess_mutex) should be used for that case, which could be
> implemented as a Windows mutex (not critical section) on Windows and
> on POSIX would be a pthread_mutex_t with PTHREADS_PROCES_SHARED
> attribute (and where supported PTHREADS_MUTEX_ROBUST)
>
> That way std::mutex is more lightweight, using the fastest
> implementation available, but only supporting a single process and not
> paying for the overhead of interprocess support (you don't pay for
> what you don't use).

For the record, I agree with your proposal.
The intent of my forwarding your original message to mingw-64 was to
draw their attention since they have been doing work in this area for
some times and the likely compiler port maintainers are there.
I do hope your patience will pay off :-)

-- Gaby