Bingo... cygserver-config script installed inconsistent path in registry.

Bingo... cygserver-config script installed inconsistent path in registry.

[Linda Walsh]

Finally tracked this down.

when I ran the cygserver-config, it installed a different
path for cygserver-config than what everything else
thinks it is running under...

I.e. even though my shell and the dbus server, both think
they are running under C:/bin (which is a symlink ->
cygwin64/bin, through C:\windows\system32\cygwin)
The cygserver-config installed C:\cygwin64\bin\cygrunsrv.exe
in the registry -- which worked for starting it, but it thought
it was a different instance than anything else.

i.e. bash, and X11 and dbus are all started off of C:\bin.

I changed the path of the service to correspond to the others
(->C:\bin\cygrunsrv.exe), and now my X server picks up the shared
memory.

(But glxgears still don't turn... -- I thought the lack of shared
memory might be a problem there, but guess its another problem).

So why didn't cygserver-config install what all the other progs
thought they were under ("C:\bin")?




--
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: Bingo... cygserver-config script installed inconsistent path in registry.

[Corinna Vinschen]

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

On Mar 21 16:03, Linda Walsh wrote:
> Finally tracked this down.
> 
> when I ran the cygserver-config, it installed a different
> path for cygserver-config than what everything else
> thinks it is running under...
> 
> I.e. even though my shell and the dbus server, both think
> they are running under C:/bin (which is a symlink ->
> cygwin64/bin, through C:\windows\system32\cygwin)

Why did you mess around with the install paths that badly?  Don't
install anything Cygwin into C:\windows.

> The cygserver-config installed C:\cygwin64\bin\cygrunsrv.exe
> in the registry -- which worked for starting it, but it thought
> it was a different instance than anything else.
> 
> i.e. bash, and X11 and dbus are all started off of C:\bin.
> 
> I changed the path of the service to correspond to the others
> (->C:\bin\cygrunsrv.exe), and now my X server picks up the shared
> memory.
> 
> (But glxgears still don't turn... -- I thought the lack of shared
> memory might be a problem there, but guess its another problem).
> 
> So why didn't cygserver-config install what all the other progs
> thought they were under ("C:\bin")?

The script just calls cygrunsrv.  cygrunsrv fetches it's own path via
the Win32 API GetModuleFileName and that API returns the path apparently
cleaned from symlinks.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: usefulness of symlinks (was: cygserver-config script installed inconsistent path in registry)

[Linda Walsh]

Corinna Vinschen wrote:
> On Mar 21 16:03, Linda Walsh wrote:
>  both think
>> they are running under C:/bin (which is a symlink ->
>> cygwin64/bin, through C:\windows\system32\cygwin)
> 
> Why did you mess around with the install paths that badly?  Don't
> install anything Cygwin into C:\windows.
----
    Strictly speaking, nothing "cygwin" is in C:\windows --
there are only "pointers" ;-)

More specifically: There are two symlinks.

    1) under C:\Windows\System32 (cygwin->C:\cygwin64)
    2) under C:\Windows\SysWOW64 (cygwin->C:\cygwin).

Why?

   Because it is the only place you can get automatic redirectly
based on what bit-size (64 v. 32) you are running at.


> The script just calls cygrunsrv.  cygrunsrv fetches it's own path via
> the Win32 API GetModuleFileName and that API returns the path apparently
> cleaned from symlinks.
---
    Is there a reason why it needs or why it should do that?

    It would be nice if there was a way to provide path transparency
to cygwin apps -- i.e. you guys do a good job of calling all the types
of redirection "symlinks", but windows doesn't really have any easy
way to remount a subpath -- might be nice to have an  option to treat
say, 'linkd' links as 'mounts' rather than symlinks, since
'mountvol' only works for complete volumes...

    I.e. linkd could be a limited substitute for mount --bind

    (reason I mention that is that I have to manually move files
after running setup)...

    Theoretically, /usr/share, should be "shareable" and contains
the most amount of data by itself.

    There might be others, but /usr/share was created to have
arch-independent data on it.

    I wouldn't call any of it a high priority item, as I doubt I'll
use 32-bit as much... but I probably will try the GLgears on 32-bit
to see if that still works there (as it doesn't on 64-bit -- gears
display but don't move, but window the gears are in is a directX
window -- 'FRAP' (Frame Rate util) displays a counter  in the window
which it only does in directX mapped windows (showing 30FPS -- it's
an LCD so doesn't need or benefit from 60).

    If it does work, I might want to continue 32 bit just for
the X-stuff until the 64bit gets sorted out... I know everyone is
doing whatever they can to make things work and all things can't
be done at the same time....  It's just that my linux distro's (opensuse)
desktops are all opening up GLX enabled windows -- so w/o that
working no remote desktop usage.  ;-(

    I was just pluggin cygwin, today over it's X-server for people
wanting a remote access to their opensuse desktops, and were talking
Xming... I know cygwin's GLX used to work... oh well.  Maybe just
a 64-bit thing.


	

--
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: usefulness of symlinks

[Jon TURNEY]

On 25/03/2014 02:09, Linda Walsh wrote:
>    I wouldn't call any of it a high priority item, as I doubt I'll
> use 32-bit as much... but I probably will try the GLgears on 32-bit
> to see if that still works there (as it doesn't on 64-bit -- gears
> display but don't move, but window the gears are in is a directX
> window -- 'FRAP' (Frame Rate util) displays a counter  in the window
> which it only does in directX mapped windows (showing 30FPS -- it's
> an LCD so doesn't need or benefit from 60).
> 
>    If it does work, I might want to continue 32 bit just for
> the X-stuff until the 64bit gets sorted out... I know everyone is
> doing whatever they can to make things work and all things can't
> be done at the same time....  It's just that my linux distro's (opensuse)
> desktops are all opening up GLX enabled windows -- so w/o that
> working no remote desktop usage.  ;-(
> 
>    I was just pluggin cygwin, today over it's X-server for people
> wanting a remote access to their opensuse desktops, and were talking
> Xming... I know cygwin's GLX used to work... oh well.  Maybe just
> a 64-bit thing.

This really reads like you've tried one GLX client (glxgears), seen that it
apparently isn't working, and decided that GLX doesn't work at all.

This is not true.  Please stop spreading misinformation.

If you have a specific GLX client which doesn't work (apart from glxgears,
which I have addressed in your other thread on the subject), please report the
problem in sufficient detail for me to try to reproduce it.

Thanks.


--
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: usefulness of symlinks

[Linda Walsh]

Jon TURNEY wrote:
> 
> This really reads like you've tried one GLX client (glxgears), seen that it
> apparently isn't working, and decided that GLX doesn't work at all.
> 
> This is not true.  Please stop spreading misinformation.
-----
I'd like to see if there is ANY GLX program that works.  I was
under the impression that GLXGEARS was among the most basic, and
it USED to work... ANY update of motion would have indicated
something is working.  I don't understand why glxgears would use
indirect rendering when client and server are on the same machine.


--
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