[PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

---
 winsup/doc/dll.xml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-winsup-doc-dll.xml-update-MinGW-.org-to-MinGW-w64-.org.patch --]
[-- Type: text/x-patch; name="0001-winsup-doc-dll.xml-update-MinGW-.org-to-MinGW-w64-.org.patch", Size: 919 bytes --]

diff --git a/winsup/doc/dll.xml b/winsup/doc/dll.xml
index f0369760f0ea..5cee0b708ead 100644
--- a/winsup/doc/dll.xml
+++ b/winsup/doc/dll.xml
@@ -103,8 +103,9 @@ you will probably want to use the complete syntax:</para>
 The name of your library is <literal>${module}</literal>, prefixed with
 <literal>cyg</literal> for the DLL and <literal>lib</literal> for the
 import library. Cygwin DLLs use the <literal>cyg</literal> prefix to 
-differentiate them from native-Windows MinGW DLLs, see 
-<ulink url="http://mingw.org">the MinGW website</ulink> for more details.
+differentiate them from native-Windows MinGW-w64 DLLs, see the 
+<ulink url="http://mingw-w64.org">GCC for Windows 64 &amp; 32 bits</ulink>
+website for more details.
 <literal>${old_libs}</literal> are all
 your object files, bundled together in static libs or single object
 files and the <literal>${dependency_libs}</literal> are import libs you 

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Jon Turney]

On 07/03/2021 16:31, Brian Inglis wrote:
> ---
>   winsup/doc/dll.xml | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)


I don't think the link here actually has much value, and would be 
inclined to drop it, as far as I can tell it's just giving that as an 
example of a toolchain which produces 'lib'-prefixed DLLs.

Also, reading the whole page, the section "Linking against DLLs" needs 
updating since GNU ld has had the ability to link directly against DLLs 
(automatically generating the necessary import stubs) for a number of years.

Also, there are other mentions of MinGW.org on the cygwin website (e.g. 
https://cygwin.com/links.html) which also need updating, if that URL is 
no longer valid.

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Brian Inglis]

On 2021-03-07 12:15, Jon Turney wrote:
> On 07/03/2021 16:31, Brian Inglis wrote:
>> ---
>>   winsup/doc/dll.xml | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)

> I don't think the link here actually has much value, and would be inclined to 
> drop it, as far as I can tell it's just giving that as an example of a toolchain 
> which produces 'lib'-prefixed DLLs.
> 
> Also, reading the whole page, the section "Linking against DLLs" needs updating 
> since GNU ld has had the ability to link directly against DLLs (automatically 
> generating the necessary import stubs) for a number of years.
> 
> Also, there are other mentions of MinGW.org on the cygwin website (e.g. 
> https://cygwin.com/links.html) which also need updating, if that URL is no 
> longer valid.

I checked the tree and Corinna cleaned up some a few years ago.

I already checked winsup/doc/ and there were no other substantive uses of MinGW 
unless you would prefer *ALL* mentions of MinGW be suffixed with -w64.

I did not look closely at cygwin-htdocs, as git complained when I tried to 
update, so I wiped that repo, but it looks like links.html and categories in 
packaging-hint-files.html which includes Mingw, needed updated.

Is there a definitive file with a list of all currently valid categories in 
calm, cygport, setup, or shared somewhere?
I may get to reclone, check, and patch htdocs later.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Corinna Vinschen]

On Mar  7 19:15, Jon Turney wrote:
> On 07/03/2021 16:31, Brian Inglis wrote:
> > ---
> >   winsup/doc/dll.xml | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> 
> I don't think the link here actually has much value, and would be inclined
> to drop it, as far as I can tell it's just giving that as an example of a
> toolchain which produces 'lib'-prefixed DLLs.

However, telling people we use cyg instead of lib for $reason, and then
not pointing to at least one project using this prefix seems puzzeling.
Given that Windows doesn't use a prefix at all, the URL to mingw-w64
might help, doesn't it?

> Also, reading the whole page, the section "Linking against DLLs" needs
> updating since GNU ld has had the ability to link directly against DLLs
> (automatically generating the necessary import stubs) for a number of years.

What do you suggest?  Shall we just remove the section entirely?

> Also, there are other mentions of MinGW.org on the cygwin website (e.g.
> https://cygwin.com/links.html) which also need updating, if that URL is no
> longer valid.

Yeah, we should remove them or move them to mingw-w64, too.


Thanks,
Corinna

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Corinna Vinschen]

On Mar  7 13:26, Brian Inglis wrote:
> On 2021-03-07 12:15, Jon Turney wrote:
> > On 07/03/2021 16:31, Brian Inglis wrote:
> > > ---
> > >   winsup/doc/dll.xml | 5 +++--
> > >   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> > I don't think the link here actually has much value, and would be
> > inclined to drop it, as far as I can tell it's just giving that as an
> > example of a toolchain which produces 'lib'-prefixed DLLs.
> > 
> > Also, reading the whole page, the section "Linking against DLLs" needs
> > updating since GNU ld has had the ability to link directly against DLLs
> > (automatically generating the necessary import stubs) for a number of
> > years.
> > 
> > Also, there are other mentions of MinGW.org on the cygwin website (e.g.
> > https://cygwin.com/links.html) which also need updating, if that URL is
> > no longer valid.
> 
> I checked the tree and Corinna cleaned up some a few years ago.
> 
> I already checked winsup/doc/ and there were no other substantive uses of
> MinGW unless you would prefer *ALL* mentions of MinGW be suffixed with -w64.
> 
> I did not look closely at cygwin-htdocs, as git complained when I tried to
> update, so I wiped that repo,

If git complained, your repo was just not in the latets state.
Maybe just using `git reset --hard origin/master' would have fixed it.


Corinna

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Brian Inglis]

On 2021-03-08 03:14, Corinna Vinschen via Cygwin-patches wrote:
> On Mar  7 13:26, Brian Inglis wrote:
>> On 2021-03-07 12:15, Jon Turney wrote:
>>> On 07/03/2021 16:31, Brian Inglis wrote:
>>>>    winsup/doc/dll.xml | 5 +++--
>>>>    1 file changed, 3 insertions(+), 2 deletions(-)

>>> I don't think the link here actually has much value, and would be
>>> inclined to drop it, as far as I can tell it's just giving that as an
>>> example of a toolchain which produces 'lib'-prefixed DLLs.
>>>
>>> Also, reading the whole page, the section "Linking against DLLs" needs
>>> updating since GNU ld has had the ability to link directly against DLLs
>>> (automatically generating the necessary import stubs) for a number of
>>> years.
>>>
>>> Also, there are other mentions of MinGW.org on the cygwin website (e.g.
>>> https://cygwin.com/links.html) which also need updating, if that URL is
>>> no longer valid.

>> I checked the tree and Corinna cleaned up some a few years ago.
>>
>> I already checked winsup/doc/ and there were no other substantive uses of
>> MinGW unless you would prefer *ALL* mentions of MinGW be suffixed with -w64.
>>
>> I did not look closely at cygwin-htdocs, as git complained when I tried to
>> update, so I wiped that repo,

> If git complained, your repo was just not in the latets state.
> Maybe just using `git reset --hard origin/master' would have fixed it.

Thanks - I'll try to remember to try that - on a pull conflict I normally try to 
checkout -- file(s), then -f, then origin/master, then plus -f, with status 
checks between, then commit -m merge when required, and re-pull origin/master to 
check resynced to upstream remote.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Achim Gratz]

Brian Inglis writes:
> Thanks - I'll try to remember to try that - on a pull conflict I
> normally try to checkout -- file(s), then -f, then origin/master, then
> plus -f, with status checks between, then commit -m merge when
> required, and re-pull origin/master to check resynced to upstream
> remote.

git status

That usually tells you what it is that prevents pulling.  Aside from
that, you can always do

git remote update

to get the objects and then figure out how to pull the branch.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Brian Inglis]

On 2021-03-08 10:38, Achim Gratz wrote:
> Brian Inglis writes:
>> Thanks - I'll try to remember to try that - on a pull conflict I
>> normally try to checkout -- file(s), then -f, then origin/master, then
>> plus -f, with status checks between, then commit -m merge when
>> required, and re-pull origin/master to check resynced to upstream
>> remote.
> 
> git status
> 
> That usually tells you what it is that prevents pulling.  Aside from
> that, you can always do

It's normally a merge conflict which will not be satisfied by regular commands 
to restore the working files to upstream.

> git remote update
> 
> to get the objects and then figure out how to pull the branch.

Thanks for that last tip which is the first I have heard of that command.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Achim Gratz]

Brian Inglis writes:
> It's normally a merge conflict which will not be satisfied by regular
> commands to restore the working files to upstream.

So you're pulling on an unclean work tree?  That's a no-no, either keep
your changes on a separate branch (that you can rebase or merge later)
or stash them away for the pull.

As Corinna said, if you're prepared to lose any local changes then

git reset --hard

will do that.  But you should be sure you really didn't want any of your
unfinished business around any more.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Ken Brown]

On 3/8/2021 2:09 PM, Achim Gratz wrote:
> Brian Inglis writes:
>> It's normally a merge conflict which will not be satisfied by regular
>> commands to restore the working files to upstream.
> 
> So you're pulling on an unclean work tree?  That's a no-no, either keep
> your changes on a separate branch (that you can rebase or merge later)
> or stash them away for the pull.
> 
> As Corinna said, if you're prepared to lose any local changes then
> 
> git reset --hard
> 
> will do that.  But you should be sure you really didn't want any of your
> unfinished business around any more.

If the unfinished business consists of local commits that haven't yet been 
applied upstream, then I typically do the following:

git fetch  # Find out if upstream has changed since my last pull.  If so...
git format-patch -n  # save n local commits
git reset --hard origin/master
git am 00*  # reapply my local commits

This assumes I've been too lazy to work on a separate branch, which is often the 
case for small changes.

Ken

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[ASSI]

Ken Brown via Cygwin-patches writes:
> If the unfinished business consists of local commits that haven't yet
> been applied upstream, then I typically do the following:
>
> git fetch  # Find out if upstream has changed since my last pull.  If so...
> git format-patch -n  # save n local commits
> git reset --hard origin/master
> git am 00*  # reapply my local commits
>
> This assumes I've been too lazy to work on a separate branch, which is
> often the case for small changes.

git branch local # optional
git rebase origin/master
git branch -D local # once you know you don't need it anymore

… does more or less the same thing.

I usually skip the safety branch since I can pull it from the reflog if
needed and it's unlikely I'll trigger a GC just that moment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Corinna Vinschen]

On Mar  8 15:20, Ken Brown via Cygwin-patches wrote:
> On 3/8/2021 2:09 PM, Achim Gratz wrote:
> > Brian Inglis writes:
> > > It's normally a merge conflict which will not be satisfied by regular
> > > commands to restore the working files to upstream.
> > 
> > So you're pulling on an unclean work tree?  That's a no-no, either keep
> > your changes on a separate branch (that you can rebase or merge later)
> > or stash them away for the pull.
> > 
> > As Corinna said, if you're prepared to lose any local changes then
> > 
> > git reset --hard
> > 
> > will do that.  But you should be sure you really didn't want any of your
> > unfinished business around any more.
> 
> If the unfinished business consists of local commits that haven't yet been
> applied upstream, then I typically do the following:
> 
> git fetch  # Find out if upstream has changed since my last pull.  If so...
> git format-patch -n  # save n local commits
> git reset --hard origin/master
> git am 00*  # reapply my local commits

I'm doing this a bit differently:

  git fetch
  git rebase -i origin/master

I like git rebase, it's a very nifty tool, especially using the
interactive mode.


Corinna

Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org

[Brian Inglis]

On 2021-03-08 13:55, Corinna Vinschen via Cygwin-patches wrote:
> On Mar  8 15:20, Ken Brown via Cygwin-patches wrote:
>> On 3/8/2021 2:09 PM, Achim Gratz wrote:
>>> Brian Inglis writes:
>>>> It's normally a merge conflict which will not be satisfied by regular
>>>> commands to restore the working files to upstream.
>>>
>>> So you're pulling on an unclean work tree?  That's a no-no, either keep
>>> your changes on a separate branch (that you can rebase or merge later)
>>> or stash them away for the pull.
>>>
>>> As Corinna said, if you're prepared to lose any local changes then
>>>
>>> git reset --hard
>>>
>>> will do that.  But you should be sure you really didn't want any of your
>>> unfinished business around any more.
>>
>> If the unfinished business consists of local commits that haven't yet been
>> applied upstream, then I typically do the following:
>>
>> git fetch  # Find out if upstream has changed since my last pull.  If so...
>> git format-patch -n  # save n local commits
>> git reset --hard origin/master
>> git am 00*  # reapply my local commits
> 
> I'm doing this a bit differently:
> 
>    git fetch

I changed to pull origin/master as I always want to get all updates;
Achim suggests remote update

>    git rebase -i origin/master

I've figured out that enough to do your tweaks without hacking patches

> I like git rebase, it's a very nifty tool, especially using the
> interactive mode.

Agreed - I trust myself more using interactive mode commands than gitk

It's been months since I had to wipe and re-clone newlib-cygwin and that's 
saying a lot.

[Thanks for all the help to a git rookie who pled orgs/projects to use/*allow* 
source/version control (often only MS SourceSafe/TeamSource? or cvs) sometimes 
on my own with whatever was/could be installed (Windows Cygwin hg, RHEL/Solaris 
cvs/rcs, Solaris/SunOS sccs/vi).]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]