Subject: MinGW-notify digest, Vol 1 #1376 - 3 msgs - msg#00019

List: gnu.mingw.announce

Date: Prev Next Index Thread: Prev Next Index

Send MinGW-notify mailing list submissions to
mingw-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx

You can reach the person managing the list at
mingw-notify-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."

This list is used to send updates of submitted patches, bug reports and file
releases. You are discouraged from posting to this list. If you wish to
unsubscribe you can do so at
https://lists.sourceforge.net/lists/listinfo/mingw-notify.

Today's Topics:

1. [ mingw-Bugs-1493668 ] Install directory for MinGW must be C:\mingw, or
linkd (SourceForge.net)
2. [ mingw-Bugs-1493668 ] Install directory for MinGW must be C:\mingw, or
linkd (SourceForge.net)
3. [ mingw-Bugs-1495207 ] Missing _strtoi64() (SourceForge.net)

--__--__--

Message: 1
To: noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx
From: "SourceForge.net" <noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx>
Date: Thu, 25 May 2006 04:56:28 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1493668 ] Install directory for MinGW must
be C:\mingw, or linkd

Bugs item #1493668, was opened at 2006-05-23 17:36
Message generated for change (Settings changed) made by alevesely
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1493668&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: website
Group: Unreproducible
>Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Ale Vesely (alevesely)
Assigned to: Earnie Boyd (earnie)
Summary: Install directory for MinGW must be C:\mingw, or linkd

Initial Comment:
Hi,
please amend that page in
http://www.mingw.org/MinGWiki/index.php/Install%20MinGW
where it says
"2. Create a directory to install all the stuff into..."

In facts the directory MUST be the root directory,
or gcc won't work. I everytime got fooled by the
fstab feature of msys. It is important that new
users understand that the fstab mounts are only
seen by the shell: native programs, including gcc,
know nothing about it.

Since Windows 2000 one can soft link a directory,
a JUNCTION in Windows parlance and overcome this
limitation, e.g.

linkd C:\mingw C:\myfancyplace\MinGW
linkd D:\mingw C:\myfancyplace\MinGW

that also solves the problem of compiling from
a different drive.

(Linkd.exe can be downloaded with the resource kit,
othe sysinternals alternatives may exist.)

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

>Comment By: Ale Vesely (alevesely)
Date: 2006-05-25 13:56

Message:
Logged In: YES
user_id=262065

Awright, I moved all mingw/gcc/* to mingw.
Then I deleted the two symbolic links.
Now gcc works when invoked from any drive,
and, if -v is given, complains that it is
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory
"/mingw/lib/gcc/mingw32/3.4.2/include"
ignoring nonexistent directory "/mingw/mingw32/include"
ignoring nonexistent directory "/mingw/include"

Some files overlapped (before moving I got:
Alessandro Vesely@NUOVO /mingw
$ find . -type f | sed 's|^[.]/gcc/|./|' | sort | uniq -c |
sort -n | egrep -v '^ *1 '
2 ./COPYING
2 ./COPYING.LIB
2 ./info/dir
2 ./lib/libiberty.a
only info/dir is documented at step 2)

Thus the correct statement is that gcc must be
installed in the mingw directory as exemplified,
or else mingw must be in (or linked from) the
root directory for gcc to work. Perhaps that's
more confusing than helpful, so please forget
this bug, unless you are willing to reword that
concept in order to document those gcc specs.

However, don't forget to mention there should be
no spaces in directory names next time you edit
that page...

Ciao
Ale

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

Comment By: Earnie Boyd (earnie)
Date: 2006-05-25 00:35

Message:
Logged In: YES
user_id=15438

Ok, then I don't know why you needed to do your linkd steps.
It isn't required by anyone else that I've heard of. I.E.:
I don't have an issue with gcc -I /include -c a.c where a.c
merely includes a.h and a.h is an empty file in /include.

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-24 18:05

Message:
Logged In: YES
user_id=262065

Yes, I have MSYS 1.0.10, it is in a parellel
directory than MinGW (see tree below.)

Earnie, I don't dare asking why that would
affect MinGW binaries execution. If by design
they can run under cmd.exe as well (as gcc
does), please say so at point 5 in that page.

I cannot read gcc specs file, however snippets like

*md_startfile_prefix:
/mingw/lib/

apparently imply that mingw should be in the root
directory.

FWIW, my tree is as follows:
$ find c:/uX -type d -maxdepth 2
c:/uX
c:/uX/MinGW
c:/uX/MinGW/bin
c:/uX/MinGW/doc
c:/uX/MinGW/gcc
c:/uX/MinGW/include
c:/uX/MinGW/info
c:/uX/MinGW/lib
c:/uX/MinGW/man
c:/uX/MinGW/mingw32
c:/uX/MinGW/uninstall
c:/uX/msys
c:/uX/msys/1.0

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

Comment By: Luke Dunstan (infidel)
Date: 2006-05-24 17:13

Message:
Logged In: YES
user_id=30442

You must install gcc, w32api and mingw-runtime in the same
tree to allow it to find the headers and libraries, not in
separate subdirectories.

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

Comment By: Earnie Boyd (earnie)
Date: 2006-05-24 13:07

Message:
Logged In: YES
user_id=15438

You mention HOME directory, are you using MSYS-1.0.10? Did
you install MSYS in the same directories as the MinGW
binaries? If, yes, that is your problem and the "Install
MinGW" page isn't discussing MSYS. MSYS-1.0.11 will allow
you to install MinGW and MSYS together.

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-24 09:06

Message:
Logged In: YES
user_id=262065

I had no spaces in paths, except for HOME.
Without links, I've been able to compile
by specifying -I, but then I couldn't link.

Perhaps I also got something else wrong
(e.g. I have both gcc and mingw32 as
subdirectories of mingw)?

I attach the output of gcc in all 3 cases:
-naive,
-using -I,
-with a junction

It contains lines like

ignoring nonexistent directory "/mingw/include"

that inspired the soft links.

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

Comment By: Earnie Boyd (earnie)
Date: 2006-05-24 01:32

Message:
Logged In: YES
user_id=15438

Your advice isn't correct and your problem is more likely to
be spaces in the path name.

I have my mingw installed in c:/opt/mingw.

I often build in e:/usr/src.

Can you please check to see if spaces in the path name is
your problem?

Earnie

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-23 19:48

Message:
Logged In: YES
user_id=262065

Yes, sysinternals has such an utility at
http://www.sysinternals.com/Utilities/Junction.html
source code is available

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1493668&group_id=2435

--__--__--

Message: 2
To: noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx
From: "SourceForge.net" <noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx>
Date: Thu, 25 May 2006 10:10:36 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1493668 ] Install directory for MinGW must
be C:\mingw, or linkd

Bugs item #1493668, was opened at 2006-05-23 11:36
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1493668&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: website
Group: Unreproducible
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ale Vesely (alevesely)
Assigned to: Earnie Boyd (earnie)
Summary: Install directory for MinGW must be C:\mingw, or linkd

Initial Comment:
Hi,
please amend that page in
http://www.mingw.org/MinGWiki/index.php/Install%20MinGW
where it says
"2. Create a directory to install all the stuff into..."

In facts the directory MUST be the root directory,
or gcc won't work. I everytime got fooled by the
fstab feature of msys. It is important that new
users understand that the fstab mounts are only
seen by the shell: native programs, including gcc,
know nothing about it.

Since Windows 2000 one can soft link a directory,
a JUNCTION in Windows parlance and overcome this
limitation, e.g.

linkd C:\mingw C:\myfancyplace\MinGW
linkd D:\mingw C:\myfancyplace\MinGW

that also solves the problem of compiling from
a different drive.

(Linkd.exe can be downloaded with the resource kit,
othe sysinternals alternatives may exist.)

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

>Comment By: Earnie Boyd (earnie)
Date: 2006-05-25 13:10

Message:
Logged In: YES
user_id=15438

Your problem as I understand it is that you install the GCC
portions in /mingw/gcc and you installed the runtime and
w32api in /mingw. The win32 version of GCC will look for
the include directory relative to the directory where the
executable lives. So if gcc.exe is in /mingw/gcc/bin/ it
will look for the default include directory to be in
/mingw/gcc/bin/../include. The install directory doesn't
need to be /mingw but you must use the same prefix directory
for the gcc, binutils, mingw-runtime and w32api packages in
order for it to work.

BTW, the page you refer to is a WikiPage. You can edit it
yourself.

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-25 07:56

Message:
Logged In: YES
user_id=262065

Awright, I moved all mingw/gcc/* to mingw.
Then I deleted the two symbolic links.
Now gcc works when invoked from any drive,
and, if -v is given, complains that it is
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory
"/mingw/lib/gcc/mingw32/3.4.2/include"
ignoring nonexistent directory "/mingw/mingw32/include"
ignoring nonexistent directory "/mingw/include"

Some files overlapped (before moving I got:
Alessandro Vesely@NUOVO /mingw
$ find . -type f | sed 's|^[.]/gcc/|./|' | sort | uniq -c |
sort -n | egrep -v '^ *1 '
2 ./COPYING
2 ./COPYING.LIB
2 ./info/dir
2 ./lib/libiberty.a
only info/dir is documented at step 2)

Thus the correct statement is that gcc must be
installed in the mingw directory as exemplified,
or else mingw must be in (or linked from) the
root directory for gcc to work. Perhaps that's
more confusing than helpful, so please forget
this bug, unless you are willing to reword that
concept in order to document those gcc specs.

However, don't forget to mention there should be
no spaces in directory names next time you edit
that page...

Ciao
Ale

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

Comment By: Earnie Boyd (earnie)
Date: 2006-05-24 18:35

Message:
Logged In: YES
user_id=15438

Ok, then I don't know why you needed to do your linkd steps.
It isn't required by anyone else that I've heard of. I.E.:
I don't have an issue with gcc -I /include -c a.c where a.c
merely includes a.h and a.h is an empty file in /include.

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-24 12:05

Message:
Logged In: YES
user_id=262065

Yes, I have MSYS 1.0.10, it is in a parellel
directory than MinGW (see tree below.)

Earnie, I don't dare asking why that would
affect MinGW binaries execution. If by design
they can run under cmd.exe as well (as gcc
does), please say so at point 5 in that page.

I cannot read gcc specs file, however snippets like

*md_startfile_prefix:
/mingw/lib/

apparently imply that mingw should be in the root
directory.

FWIW, my tree is as follows:
$ find c:/uX -type d -maxdepth 2
c:/uX
c:/uX/MinGW
c:/uX/MinGW/bin
c:/uX/MinGW/doc
c:/uX/MinGW/gcc
c:/uX/MinGW/include
c:/uX/MinGW/info
c:/uX/MinGW/lib
c:/uX/MinGW/man
c:/uX/MinGW/mingw32
c:/uX/MinGW/uninstall
c:/uX/msys
c:/uX/msys/1.0

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

Comment By: Luke Dunstan (infidel)
Date: 2006-05-24 11:13

Message:
Logged In: YES
user_id=30442

You must install gcc, w32api and mingw-runtime in the same
tree to allow it to find the headers and libraries, not in
separate subdirectories.

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

Comment By: Earnie Boyd (earnie)
Date: 2006-05-24 07:07

Message:
Logged In: YES
user_id=15438

You mention HOME directory, are you using MSYS-1.0.10? Did
you install MSYS in the same directories as the MinGW
binaries? If, yes, that is your problem and the "Install
MinGW" page isn't discussing MSYS. MSYS-1.0.11 will allow
you to install MinGW and MSYS together.

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-24 03:06

Message:
Logged In: YES
user_id=262065

I had no spaces in paths, except for HOME.
Without links, I've been able to compile
by specifying -I, but then I couldn't link.

Perhaps I also got something else wrong
(e.g. I have both gcc and mingw32 as
subdirectories of mingw)?

I attach the output of gcc in all 3 cases:
-naive,
-using -I,
-with a junction

It contains lines like

ignoring nonexistent directory "/mingw/include"

that inspired the soft links.

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

Comment By: Earnie Boyd (earnie)
Date: 2006-05-23 19:32

Message:
Logged In: YES
user_id=15438

Your advice isn't correct and your problem is more likely to
be spaces in the path name.

I have my mingw installed in c:/opt/mingw.

I often build in e:/usr/src.

Can you please check to see if spaces in the path name is
your problem?

Earnie

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

Comment By: Ale Vesely (alevesely)
Date: 2006-05-23 13:48

Message:
Logged In: YES
user_id=262065

Yes, sysinternals has such an utility at
http://www.sysinternals.com/Utilities/Junction.html
source code is available

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1493668&group_id=2435

--__--__--

Message: 3
To: noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx
From: "SourceForge.net" <noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx>
Date: Thu, 25 May 2006 15:26:27 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1495207 ] Missing _strtoi64()

Bugs item #1495207, was opened at 2006-05-26 00:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1495207&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Loïc GUILLOUX (glx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing _strtoi64()

Initial Comment:
Hi,

_strtoi64() is missing in stdlib.h and libmsvcrt.a but
it is present in msvcrt.dll (works if I declare it in
my app and link against msvcrt.dll).

Thanks.

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1495207&group_id=2435

--__--__--

_______________________________________________
MinGW-notify mailing list
MinGW-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/mingw-notify

End of MinGW-notify Digest

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

MinGW-notify digest, Vol 1 #1375 - 1 msg

Send MinGW-notify mailing list submissions to mingw-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/mingw-notify or, via email, send a message with subject or body 'help' to mingw-notify-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx You can reach the person managing the list at mingw-notify-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of MinGW-notify digest..." This list is used to send updates of submitted patches, bug reports and file releases. You are discouraged from posting to this list. If you wish to unsubscribe you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify. Today's Topics: 1. [ mingw-Bugs-1424461 ] Avoidable namespace pollution in win32api (SourceForge.net) --__--__-- Message: 1 To: noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx From: "SourceForge.net" <noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx> Date: Wed, 24 May 2006 18:28:39 -0700 Subject: [Mingw-notify] [ mingw-Bugs-1424461 ] Avoidable namespace pollution in win32api Bugs item #1424461, was opened at 2006-02-05 23:26 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1424461&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ron (ronl) Assigned to: Danny Smith (dannysmith) Summary: Avoidable namespace pollution in win32api Initial Comment: Hi, Could we please uglify the #define'd "psuedo modifiers", IN, OUT, and OPTIONAL (perhaps others) in win32api? It is the latter which has burned the code I'm presently porting, being the name of an enum, nested in a class, in a named namespace. It appears even the gcc source dist that mingw releases uses OPTIONAL as an enum value, so I'm not alone in thinking it is fair game in my own code. I can't find anything that indicates this is for compatibility with "native stupidity", and they are all defined to nothing, so the name seems quite arbitrary and safe to change to something a little less collision prone. I can whip up a patch to fix this if we can agree on a suitable name mangling (or you'll take whatever I pick;), but its a pretty simple seach and replace in not too many files -- so ping me if that will be helpful. cheers, Ron ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2006-05-25 13:28 Message: Logged In: YES user_id=11494 > Is there still hope? dum spiro, spero No objections to my last ping so far, so I take it that this is OK Will wait 72 hrs then commit an updated version. Danny ---------------------------------------------------------------------- Comment By: Ron (ronl) Date: 2006-05-21 00:47 Message: Logged In: YES user_id=78887 Hi. I see 3.7 is out, and this was not applied to it. Is there still hope? cheers, Ron ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-03-07 09:00 Message: Logged In: YES user_id=11494 Ping. Are there still objections after Ron's suggestion to: > If people are likely to (or do for certain) use them in > their code and expect them to be defined, then we can > retain full compatibility by default simply by adding: > >#ifndef W32_NO_PSUEDO_MODIFIERS // or something appropriate > #define IN __W32_IN > #define OUT __W32_OUT > #define OPTIONAL __W32_OPTIONAL > #endif > > to the previous patch, in some suitable place. Danny ---------------------------------------------------------------------- Comment By: Ron (ronl) Date: 2006-02-10 06:36 Message: Logged In: YES user_id=78887 Ok. I've just had a report that PWLib definitely uses 'IN', so it seems at least some people have used them. I would hope that we can still apply this patch, as an enhancement, with the existing behaviour provided by defining IN, OUT, and OPTIONAL, inside of a guard that people may define to enable the enhancement (and use code that uses these symbols without modification). Recommending that people #define IN IN #define OUT OUT #define OPTIONAL OPTIONAL after including all w32api headers, seems like a poor second option if we do not do something like this. Thanks! Ron ---------------------------------------------------------------------- Comment By: Ron (ronl) Date: 2006-02-07 02:29 Message: Logged In: YES user_id=78887 ... also while making the patch, I noted the prior Changelog entries: Jun 22 2000 Christopher Faylor * rpcdce.h: Protect OPTIONAL definition since it may be (legally) previously defined. 1998-12-02 Anders Norlander * include/rpcproxy.h: Removed IN, OUT and OPTIONAL since they are meaningless. The former may mean a number of things (may it legally be defined to "any" value? -- obviously not if it is to work as it does at present), but the latter made me wonder whether I should not be using // as my replace string... That seemed like not my decision to make though, so I stuck to the plan. ---------------------------------------------------------------------- Comment By: Ron (ronl) Date: 2006-02-07 02:16 Message: Logged In: YES user_id=78887 Indeed, I noticed they were used in (some older) msdn documentation while checking a signature that looked a little odd when I was making the patch... I would (have) be(en) personally inclined to interpret it as a documentation convention in the msdn, and not at all surprised to learn that the symbols themselves do not exist anywhere in OEM headers -- though I don't know that as fact, having never posessed, let alone seen them... (I don't know if we can confirm this cleanly one way or the other??) But that is no matter if Earnie's concern is real. If people are likely to (or do for certain) use them in their code and expect them to be defined, then we can retain full compatibility by default simply by adding: #ifndef W32_NO_PSUEDO_MODIFIERS // or something appropriate #define IN __W32_IN #define OUT __W32_OUT #define OPTIONAL __W32_OPTIONAL #endif to the previous patch, in some suitable place. Then (otherwise) portable code, that did not originate with msdn conventions, can be built on that platform without changing symbols that under most conventions, should belong to them (at least in their own namespace). I'd probably prefer the default to be NOT to define them, but this seems like a reasonable compromise that allows both the msdn and other standards to co-exist side by side. Does that satisfy your concern Earnie, or is there more that I miss? cheers, Ron ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-02-07 01:36 Message: Logged In: YES user_id=15438 Consider this an objection. These psuedo modifiers are documented in MSDN. Should we change the what they are? I don't consider this a bug. It is more a request for enhancement. ---------------------------------------------------------------------- Comment By: Ron (ronl) Date: 2006-02-06 21:35 Message: Logged In: YES user_id=78887 Ok. The patch is too big to attach here. (and the web interface (c)rudely dumped the comments I first wrote too) So you can grab it from: http://people.debian.org/~ron/mingw/02-in_out_optional_ugly.patch If __W32_ is no good it should be trivial to patch the patch. There is a little bit of whitespace normalisation (mostly s/[\t]/ / to make the search and replace a bit simpler, making the affected code look like the rest around it) which touches some other lines in those files -- but the diff -bd isn't significantly smaller. Tested ok on all the code I threw at it here. I'll upload mingw-runtime_3.9-3 to Debian shortly which might help anything I may have missed float to the top. Thanks! Ron ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-02-06 09:51 Message: Logged In: YES user_id=11494 Hello Ron I would suggest __W32_IN, __W32_OUT, __W32_OPTIONAL, but I'm not fussy about the colour of the bike shed. If no one objects to that colour of ugliness in the next 24 hours, I'll apply the patch to prefix __W32_. Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1424461&group_id=2435 --__--__-- _______________________________________________ MinGW-notify mailing list MinGW-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/mingw-notify End of MinGW-notify Digest

Next Message by Date: click to view message preview

MinGW-notify digest, Vol 1 #1377 - 1 msg

Send MinGW-notify mailing list submissions to mingw-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/mingw-notify or, via email, send a message with subject or body 'help' to mingw-notify-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx You can reach the person managing the list at mingw-notify-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of MinGW-notify digest..." This list is used to send updates of submitted patches, bug reports and file releases. You are discouraged from posting to this list. If you wish to unsubscribe you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify. Today's Topics: 1. [ mingw-Bugs-1475483 ] mount Function not implemented (SourceForge.net) --__--__-- Message: 1 Date: Fri, 26 May 2006 19:20:12 -0700 To: noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx From: "SourceForge.net" <noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx> Subject: [Mingw-notify] [ mingw-Bugs-1475483 ] mount Function not implemented Bugs item #1475483, was opened at 04/24/06 05:00 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1475483&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: None >Status: Closed Resolution: Remind Priority: 5 Submitted By: anatoly techtonik (techtonik) Assigned to: Earnie Boyd (earnie) Summary: mount Function not implemented Initial Comment: Can't mount a path in MSYS. --- user@STATION /etc $ mount help mount: not enough arguments Usage: mount [OPTION] [<win32path> <posixpath>] ... user@STATION /etc $ mount d:/temp /e2 mount: /e2: Function not implemented user@STATION /etc $ mount d:\temp /e2 mount: /e2: Function not implemented user@STATION /etc $ cd /d/temp user@STATION /d/temp $ --- ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 05/26/06 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 30 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 04/28/06 06:11 Message: Logged In: YES user_id=823908 FWIW, I've attached a pair of rough and ready scripts, which provide rudimentary mount/umount manipulation of /etc/fstab, directly from the command line. I've not attempted to make them especially robust, but used sensibly, they get the job done. To deploy them, unpack the tarball into /bin, and rename to remove the `.sh' extensions. Do note that they continue to (ab)use the /etc/fstab file, as if it were /etc/mnttab, so I've not provided any of the functionality which is normally attributed to /etc/fstab, (/etc/vfstab on SunOS); neither have I included any support for mount options -- syntax is restricted to: mount mount win32path mountpoint umount mountpoint umount win32path ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 04/26/06 11:00 Message: Logged In: YES user_id=823908 > Are changes to /etc/mnttab persistent across login sessions? Changes to /etc/fstab are, at present. If we modifiy the DLL code to read /etc/mnttab instead of /etc/fstab, then that should continue to be the case. We could then redesignate /etc/fstab to work with a modified mount command, to specify default mount points for paths we want to "mount" intermittently, just as it would be used on a modern *nix system. Even without the modification, we could kludge something that would offer similar functionality, but the file name usage might seem odd, to users coming from a *nix background. > BTW where are sources for mount.exe ? I can't find them via ViewCVS. Neither ViewCVS nor anonymous CVS are reliable sources on SF at present; the content of these repositories have not been updated, to match the development status, for several weeks now, following a hardware failure. See the SF Site Status page for more info. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 04/26/06 07:33 Message: Logged In: YES user_id=15438 http://cvs.sourceforge.net/viewcvs.py/mingw/msys/rt/src/winsup/utils/ uses http://cvs.sourceforge.net/viewcvs.py/mingw/msys/rt/src/winsup/cygwin/ uses http://cvs.sourceforge.net/viewcvs.py/mingw/msys/rt/src/newlib/ ---------------------------------------------------------------------- Comment By: anatoly techtonik (techtonik) Date: 04/26/06 06:47 Message: Logged In: YES user_id=669020 The idea with automatic modification of /etc/mnttab seems rather good to me. Are changes to /etc/mnntab persistent across login sessions? BTW where are sources for mount.exe ? I can't find them via ViewCVS. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 04/26/06 04:22 Message: Logged In: YES user_id=15438 Yes, it is a bug I need to get to that adding a device while msys-1.0.dll is active in memory doesn't DDTRT. Closing your MSYS session and reopening or touching the /etc/fstab would have allowed cp foo /e to work. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 04/25/06 15:29 Message: Logged In: YES user_id=823908 Curiously, I've recently been giving some thought to this. Working with USB storage media can be a bit of a pain, and I've found that editing /etc/fstab can help MSYS to actually recognise that /e really does mean the hot-plug media device I just plugged in, rather than a *file* called /e -- yes that happened to me yesterday; `cp foo /e' created a file called /e, instead of putting a copy of foo on my memory stick! To solve this, I found I needed to edit /etc/fstab, adding the line `e:/ /usb', so adding /usb to the internal mount table, and then `cp foo /usb' did the deed. This got me to thinking that a pair rudimentary scripts, emulating the most basic syntax of mount and umount, and simply adding or removing lines from /etc/fstab on demand, and so capitalising on the dynamic mapping feature, might be convenient. I haven't yet had time to develop the idea further, but if I do, I'll certainly share it. It would be nice, although not essential, if MSYS *did* read /etc/mnttab -- this, with the double `t' is, IIRC, the name commonly used in UNIX systems -- instead of /etc/fstab. That way we more closely emulate modern UNIX behaviour; otherwise we would have to insist on: mount realpath virtualpath umount eitherpath (Of course we could still let mount with no args invoke `/bin/mount.exe', to display the current mount table). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 04/25/06 03:57 Message: Logged In: YES user_id=15438 When /etc/fstab is modified the mount points are refactered dynamicly. There are a few bindings that are necessary for the operation of MSYS those cannot be changed by the user. I would be appreciative of modification to the MSYS mount code to allow a user to define mount points in /etc/fstab and then control those mounts with /etc/mntab. Then mount would change /etc/mntab based on /etc/fstab and MSYS would read /etc/mntab for the changes dynamicly. I will not personally do this because I don't really see the need since changing /etc/fstab will dynamicly change the internal mount table. ---------------------------------------------------------------------- Comment By: anatoly techtonik (techtonik) Date: 04/24/06 21:44 Message: Logged In: YES user_id=669020 Quote: "These automatic file system bindings are not changable by the user. User defined file system bindings can be created by specifying them in the /etc/fstab directory as explained in table 2." This doesn't explain why it is not possible to make user defined file system bindings work at runtime? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 04/24/06 09:26 Message: Logged In: YES user_id=15438 See the /doc/msys directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1475483&group_id=2435 --__--__-- _______________________________________________ MinGW-notify mailing list MinGW-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/mingw-notify End of MinGW-notify Digest

Previous Message by Thread: click to view message preview

Next Message by Thread: click to view message preview

Loading Comments...