Re: Question on gcc install

[René Berber]

On 6/21/2014 9:13 PM, JonY wrote:


There you go again with all the implications, mingw32 code is cross
compiled from Cygwin's point of view, so don't run it under Cygwin. Run
it under cmd or something.

Was that too hard to understand?


Yes, because its not true, the code runs fine under Cygwin (as long as 
the executable and its dependencies are in the PATH, or on the current 
working directory, and all of them have the executable attribute set, 
i.e. it follows Windows' rules) the same as any other Windows program 
runs under Cygwin.

--
René Berber


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question on gcc install

[JonY]

On 6/22/2014 00:43, Arthur Schwarz wrote:
>> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
>> error while loading shared libraries: libstdc++-6.dll: cannot open 
>> shared object file: No such file or directory
>>
>> RUN FAILED (exit value 127, total time: 15ms)
>>
> 
> You are not supposed to run cross compiled executable files. This is not
> even a linker error.
> 
> I compiled my program with each of the mingw32 compilers.
> After each compilation I copied the libstdc++-6.dll into
> the directory containing the compiled executable and then
> ran the compiled code. After each execution I received the
> same error. Are you saying that the mingw32 compiled code
> is cross-compiled to a non-intel, non-windows and/or
> non-cygwin architecture and that is why the code doesn't
> execute? What are you supposed to do with mingw32 compiled
> code instead of executing it?
> 
> 

There you go again with all the implications, mingw32 code is cross
compiled from Cygwin's point of view, so don't run it under Cygwin. Run
it under cmd or something.

Was that too hard to understand?




signature.asc
Description: OpenPGP digital signature

Re: Trusted vs untrusted ssh/X connections

[Larry Hall (Cygwin)]

On 06/20/2014 02:37 PM, Andrew DeFaria wrote:

On 6/19/2014 7:37 PM, Larry Hall (Cygwin) wrote:

On 06/19/2014 04:25 PM, Andrew DeFaria wrote:

This is something that's been bothering me for a long time and I
thought I
might look into it a little deeper. I'm not sure if I should post this
here
because it involves Cygwin/X but it also involves OpenSSh.


Actually, this is probably off-topic since I don't see anything Cygwin-
specific about setting up ssh/X connections.


But I get the "untrusted X11 forwarding" error only when I ssh from Cygwin
-> Linux using -X.


OK, I see your point on this one.  But I thought that was covered in this
FAQ:



My understanding is that the Cygwin X server would need to be built
with the SECURITY extension but that it is not and, for reasons discussed
in the referenced email, (which you also pointed to) would not be.  If you
want to re-open this discussion, I suggest you create a new thread on the
Cygwin X list and refer back to this one (for background and continuity).
I'm not sure that there has been any big change in this area in the last 6
years but there's certainly nothing wrong with asking. :-)




When I ssh into a Linux machine using ForwardX11 I get those familiar
messages:

Warning: untrusted X11 forwarding setup failed: xauth key data not
generated

and according to
https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html:
The warning can be silenced by using ssh -Y, since that
is what ssh -X is doing now anyway.

However, I find -Y to be 20 times slower to log in than -X:


This is probably a configuraton issue since when I ssh into my Linux
system,
login time is roughly equivalent.


Any ideas of what configuration file I should be looking and what that
configuration option that would be?


I'm not sure.  It might be as simple as the permissions problem on
.Xauthority slowing you down.  Alternatively, you might try running
both clients with debugging and/or under strace to see if it helps
you narrow down where the time is going in the "-Y" case.


Adefaria-lt:time ssh cm-job-ldev01 echo 'hi'
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11
forwarding.
/usr/bin/xauth:  error in locking authority file
/home/adefaria/.Xauthority
hi

real0m2.387s
user0m0.075s
sys 0m0.446s
Adefaria-lt:time ssh -Y cm-job-ldev01 echo 'hi'
Warning: No xauth data; using fake authentication data for X11
forwarding.
hi
/usr/bin/xauth:  error in locking authority file
/home/adefaria/.Xauthority

real0m22.476s
user0m0.091s
sys 0m0.477s
Adefaria-lt:

Bonus points if you can help me get right of the other errors!


I believe the error regarding the .Xauthority file has something to do with
the permissions on the file.  As for the warning, I believe you want to
unset DISPLAY on your PC, set X11Forwarding to "yes" on your Linux machine
in your sshd_config file, and X11Forward to "yes" in you ssh_config file
(for instance) on your PC.  At least, that's what I gathered from searching
around on the net for the information. :-)


My experience with this is that if DISPLAY is not set and you ssh -X (or -Y)
then on the other side DISPLAY is not set:

Adefaria-lt:echo $DISPLAY
:0
Adefaria-lt:ssh cm-job-ldev01 'echo $DISPLAY'
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  error in locking authority file /home/adefaria/.Xauthority
localhost:11.0
Adefaria-lt:unset DISPLAY
Adefaria-lt:ssh cm-job-ldev01 'echo $DISPLAY'

Adefaria-lt:


That's not what the man page says and doesn't match my experience either.
Check out 'man ssh' and search for the section on "X11 FORWARDING".  It
has a section on what's supposed to happen and what needs to be set on the
client side to make this happen.  That handles the client-side
requirements.  Then there's the "X11Forwarding" on the server side that
needs to be set too, like I mentioned above.  If this is how you're running
things but still having troubles, I would recommend contacting the OpenSSH
folks.  They may have specific ideas about what else could cause the
behavior you see despite the recommended settings.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Too many mailing lists

[Andrey Repin]

Greetings, Warren Young!

> The Cygwin project has too many mailing lists.  This causes an 
> unjustifiable amount of friction.

Eh? Wait a second, please. Let me pull my fingers up and count.
So far, barring automatic mailing lists like -announce, we have:
1. cygwin (this exact one)
A common mailing list for all things Cygwin. Frankly, very, VERY few things
are off-topic here. With exception of /X stuff, for which there's a clearly
separated, specific list (who you are, if you did not find it from browsing
the website?), about everything cygwin-related goes here.
2. cygwin-xfree (for all things related to the version of X on Cygwin)
As mentioned above, this is the end point for all things/X that is
Cygwin-related. As vast as it can be, not everyone's interested in intricacies
of setting up and using X environment under Cygwin. I, for one, don't.
3. cygwin-talk (a non-technical barely-cygwin related list)
Smokers' room, if you allow me this association.
4. cygwin-apps (a list for PACKAGE MAINTAINERS)
Clearly labelled, this list is for questions about packaging and distribution
of applications under cygwin banner. Nobody have any interested in it, except
active package maintainers.
5. cygwin-patches
This one's going to be missing as soon as the Cygwin repo is migrated to Git,
IMO.
6. cygwin-developers
I think it's clear from the name. The list for developers of Cygwin itself.
7. cygwin-licensing a list for people who need some lawe.
I have no interest in this kind of questions, but I see them popping around
every now and then. I don't understand them, but it seems, they are rather
important for some people.

> Every time someone says "That's not on topic here, go elsewhere," it can
> easily be read as "Go away." 
Every time I remember a reply similar to this, it was not "go elsewhere", but
rather "go to ". Which looks far from "go
away", to my untrained eye.
(Of course, I'm not including the results from late... erm... "discussion"...
you know, which one I mean... where it was explicitly stated to "go away", and
explained, why.)

> The Cygwin project should only be pushing away toxic people, and multiple
> mailing lists do not have that happy side effect.

I can only see seven lists, of which one is barely cygwin-related, one is
unrelated, and three are developers-only mailing lists.
What's left? Two lists? Hooray, we have ALOT of two mailing lists, where a
question can misdirect!
/shame


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 22.06.2014, <05:01>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

man-db requires line

[Buchbinder, Barry (NIH/NIAID) [E]]

On 32 bit cygwin.

man wasn't working for me; it complained was missing iconv.  The man-db
requires line includes libiconv2.  cygcheck -c reported that libiconv2
was OK.

I installed libiconv.  man now works.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Question on gcc install

[Arthur Schwarz]

On 6/20/2014 22:37, Arthur Schwarz wrote:
> 
>> At the present time /bin/gcc.exe, etc., works. /bin/*mingw*.exe 
>> either compiles but does not link, or does not compile - which seems 
>> to be a
> header
>> issue. gcc -m32 does not work which may be a gcc.gnu issue.
>>
> 
> Can you at least be specific about the errors? It is rather 
> frustrating reading your emails, being so vague about and all. Are you 
> mixing Cygwin and mingw code?
> 
>Sorry. I was remiss.
> 
>Execution fails on all of the mingw compilers with the same error
>message. All compilations use the same command line options.
> 
>> i686-pc-mingw32-g++ -Wall -Wno-reorder -Wno-unused-value -DYYDEBUG=1 
>  -DDEBUG_IO   -c -g -MMD -MP -MF
> 
>> slip.exe
> 
> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
> error while loading shared libraries: libstdc++-6.dll: cannot open 
> shared object file: No such file or directory
> 
> RUN FAILED (exit value 127, total time: 15ms)
> 

You are not supposed to run cross compiled executable files. This is not
even a linker error.

I compiled my program with each of the mingw32 compilers.
After each compilation I copied the libstdc++-6.dll into
the directory containing the compiled executable and then
ran the compiled code. After each execution I received the
same error. Are you saying that the mingw32 compiled code
is cross-compiled to a non-intel, non-windows and/or
non-cygwin architecture and that is why the code doesn't
execute? What are you supposed to do with mingw32 compiled
code instead of executing it?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Too many mailing lists

[Adam Dinwoodie]

On Fri, Jun 20, 2014 at 03:07:37PM -0600, Warren Young wrote:
> Every time someone says "That's not on topic here, go elsewhere," it
> can easily be read as "Go away."  The Cygwin project should only be
> pushing away toxic people, and multiple mailing lists do not have
> that happy side effect.

I've never seen a reply saying "that's not on topic here, go away" that
could be read as you describe.  What I see is "please take this to the
correct list", with the occasional person who can't follow that explicit
instruction being unsubscribed or banned from the list in question.

> We're long past the days when server-side list traffic segregation
> made sense.  With today's powerful mailers and search engines, we no
> longer need lots of mailing lists to manage the flow.

We don't *need* lots of mailing lists, but relying on mailer filtering
and search engines means I need to set up the filtering myself and rely
on other users giving their emails easy-to-filter subject lines.  That's
much easier for people to get wrong than working out which mailing list
to use.

> I see real value in only 3 lists:
> 
>   1. User discussions
>   2. Development of Cygwin-the-project (broader than the DLL)
>   3. Talk
> 
> Specifically:
> 
> 1. User discussions: Everything now allowed on the licensing and
> apps lists should be allowed on the main list.  Posts on use of
> Cygwin/X and Cygwin Ports should be welcome, too.  Nontechnical
> packaging questions should be allowed, if only to encourage more
> Cygwin users to adopt packages.

I don't use X.  It's an easy and obvious thing to filter out, and it
means I don't have my inbox filled with posts about X when I simply
don't care about it.

Most users won't care about app packaging.  I do, so I'm subscribed to
that list.  When I post there about packaging apps, I'm not going to be
filling folks' inboxes with things they're not interested in, and I'm
also not going to be inviting the opinions of people who aren't involved
in it.

Cygwin Ports is officially not supported here.  That, by my
understanding, is pretty much the whole point of Cygwin Ports.  Offering
support for it here is only going to cause confusion.

> 2. Development of Cygwin: I propose that the -devel list be the
> place for anything that affects -- or potentially *can* affect --
> one of the Cygwin project's code repositories.  The only good reason
> to separate the Cygwin DLL traffic has to do with legal matters, and
> that cut doesn't have to be made at the mailing list level.
> Legally, all that matters is what's checked into the winsup/cygwin
> section of the CVS repo, and that's covered by policy and
> permissions.  Discussions involving changes to setup.exe, the docs,
> the web pages, the scripts running things behind the scenes, etc.
> all should be allowed on -devel.  Patches and commit messages, too;
> they're easy to filter out.

I don't use devel, but I suspect that has a whole bunch of similar
issues.

> 3. Talk: I'm in favor of keeping this one as-is only because of
> restrictions in some work environments.  I'd prefer to live in a
> world where a little off-topic chatter was okay on the main list,
> but I will concede that it's worth segregating the "vulgar and
> unprofessional" threads if it keeps more people subscribed to the
> main list.

Plus being able to filter out things on the mailing list that aren't
relevant to actually using Cygwin seems like a useful ability.

> I am uncertain about -announce.  It echoes to the main list already;
> that part of its value could be replaced by asking package
> maintainers to prepend [ANNOUNCEMENT] to subject lines.  It may be
> the case that there are a large number of people who choose to
> subscribe to this list and not to any other Cygwin list.  Do the
> statistics bear this out?  If not, it is not providing much value.

Even if nobody subscribes directly to it, I fail to see what harm it
does, and it gives a one-stop location for people who are interested in
updates to Cygwin packages but who have no interest in the discussions.

> More generally, I believe that threads should be allowed to continue
> where they started, no matter what a wall-of-text web page --
> clearly in low regard -- says.  As long as the discussion is
> productive, does it really matter where it happens?  The purity of
> each list's archive has little value in this modern world.  I don't
> believe Google makes distinctions between pages it finds under
> cygwin.com/ml based on which list the post was sent to.

I only have so many hours in each day, and I like to keep abreast of the
bits of Cygwin I'm interested in.  Amalgamating the lists would increase
the noise in my inbox without increasing the interesting content, or
would require me to set up complex filtering rules that would rely on
folk correctly describing their problems in their first email, which
seems like no less effort than picking the right mailing list in the
first place.

--
Problem reports:   http://cygwin.c