Re: xpdf relocation error

[Mark Geisert]

Jaakov Jaakov  ro.ru> writes:
> Dear Mark et al., dear developers:
> 
> Finally I got the culprit machine again.
> 
>  > Sorry but my suspicion expressed earlier, that there's an address 
> 
>  > collision, was incorrect.   The rebase source code shows it's a 
Windows 
> 
>  > error code being reported, and it's Windows' ReBaseImage64() 
function 
> 
>  > itself having some issue operating on the cygXt-6.dll file.   Do 
you have 
> 
>  > write access to that file and its directory?
> 
>  I do. Here we go (started from a non-X terminal):
> 
> admin  hostname:~$ xpdf
> 
>  Cygwin runtime failure: /usr/bin/xpdf.exe: Invalid relocation.   
Offset 0x2f6e3bad9 at address
> 0x100494523 doesn't fit into 32 bits
> 
> admin  hostname:~$ ls -la /usr/bin/cygXt-6.dll
> 
>  -rwxr-xr-x 1 admin None 333855 29. Jan 21:27 /usr/bin/cygXt-6.dll
> 
> admin  hostname:~$ ls -la /usr/
> 
>  insgesamt 920
> 
>  drwxr-xr-x+ 1 admin None 0 28. Nov 13:24 .
> 
>  drwxr-xr-x+ 1 admin None 0 15. Aug 2015   ..
> 
>  drwxr-xr-x+ 1 admin None 0 17. Apr 22:23 bin
> 
>  ...
> 
>  As we see, the write attributes for "admin" are set, and I am "admin" 

That all looks perfectly normal to me, and exactly what I see on my own 
systems.  But your explicit mention of using a non-X terminal suggested 
another possible reason for rebase failure: the cygXt-6.dll is very 
likely to be in-use, and thus busy as far as Windows is concerned, if 
you're running an X server and/or xterms etc. at the same time you're 
trying to rebase that DLL.

Try closing all xterms, background X apps, and the X server and any X 
window manager you may be running.  All processes related to X, in other 
words.  Then retry the rebase of cygXt-6.dll.

..mark





--
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: cmp missing from base

[Warren Young]

On May 6, 2016, at 3:53 AM, Thomas Wolff  wrote:
> 
> after a recent fresh installation of cygwin, I was surprised that `cmp` was 
> missing, which is part of the traditional Unix base commands.
> I think the diffutils package should be part of the base installation.

We’ve never really had a hard rule on what is in Base and what isn’t.  It’s 
always been a judgement call.

I wonder if the rule should just be “POSIX”?  That is, if it’s on this page, it 
should be in Base:

  http://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html

That would exclude other things we’ve always excluded, such as Perl.

I’m not suggesting that we make this rule a strict one.  Most importantly, it 
cannot be an exclusion rule: Cygwin must contain things not in POSIX.  I’m just 
suggesting that it would be nice if Cygwin were as close to POSIX as practical 
out-of-the-box.

By that latter, I mean without extra effort other than adjusting some 
setup.hint files.  I mean, if there is a command on that list that doesn’t even 
have a Cygwin package, I don’t mean to propose with this rule that someone must 
go out and package it just to satisfy POSIX.

As a counterexample, that list contains pax(1), which is currently in Archive, 
not Base, so by that rule, pax(1) should also move to Base.

By that very example, though, I can argue against this proposed rule: as I 
understand it, pax(1) was added to POSIX at the same time they dropped cpio(1) 
and tar(1), thinking that by doing so, they’d change existing practice, moving 
everyone over to pax(1).  That just created a Standard in the XKCD sense:

  https://xkcd.com/927/
--
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: a recent 32-bit Cygwin install completed with these Unknown package messages

[Marco Atzeri]

On 06/05/2016 20:10, Kenneth Wolcott wrote:

Hi;

a recent (last night into this morning) 32-bit Cygwin initial install
completed with these Unknown package messages

Package: _/Unknown package
mingw64-x86_64-glib2.0-networking.sh exit code 126
mingw64-x86_64-librsvg2.sh exit code 126
mingw64-x86_64-libwmf.sh exit code 126
x3270.sh exit code 1

Is it important/valuable to report these anomalies when they happen?

Thanks,
Ken Wolcott



looks for details on /var/log/setup.log.full

x3270.sh failure is probably due to the changes
on managing font. I would not worry about it.


You can also run the scripts directly

/etc/postinstall/mingw64-x86_64-glib2.0-networking.sh

to see if it was a glitch or if the problem is still present.

The scripts that run correctly can be renamed as

/etc/postinstall/mingw64-x86_64-glib2.0-networking.sh.done

PS: the special 0* and zp* script are always run and never renamed.

Regards
Marco

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

a recent 32-bit Cygwin install completed with these Unknown package messages

[Kenneth Wolcott]

Hi;

a recent (last night into this morning) 32-bit Cygwin initial install
completed with these Unknown package messages

Package: _/Unknown package
mingw64-x86_64-glib2.0-networking.sh exit code 126
mingw64-x86_64-librsvg2.sh exit code 126
mingw64-x86_64-libwmf.sh exit code 126
x3270.sh exit code 1

Is it important/valuable to report these anomalies when they happen?

Thanks,
Ken Wolcott

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

xpdf relocation error

[Jaakov Jaakov]

Dear Mark et al., dear developers:

Finally I got the culprit machine again.

> Sorry but my suspicion expressed earlier, that there's an address 

> collision, was incorrect.   The rebase source code shows it's a Windows 

> error code being reported, and it's Windows' ReBaseImage64() function 

> itself having some issue operating on the cygXt-6.dll file.   Do you have 


> write access to that file and its directory?

I do. Here we go (started from a non-X terminal):

admin@hostname:~$ xpdf

Cygwin runtime failure: /usr/bin/xpdf.exe: Invalid relocation.   Offset 
0x2f6e3bad9 at address 0x100494523 doesn't fit into 32 bits

admin@hostname:~$ ls -la /usr/bin/cygXt-6.dll

-rwxr-xr-x 1 admin None 333855 29. Jan 21:27 /usr/bin/cygXt-6.dll

admin@hostname:~$ ls -la /usr/

insgesamt 920

drwxr-xr-x+ 1 admin None 0 28. Nov 13:24 .

drwxr-xr-x+ 1 admin None 0 15. Aug 2015   ..

drwxr-xr-x+ 1 admin None 0 17. Apr 22:23 bin

...


As we see, the write attributes for "admin" are set, and I am "admin" 



Best regards,

Jaakov
--
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: Invalid relocation for xpdf

[Jaakov Jaakov]

Finally I got the culprit machine again.

Sorry but my suspicion expressed earlier, that there's an address 


collision, was incorrect.  The rebase source code shows it's a Windows 


error code being reported, and it's Windows' ReBaseImage64() function 


itself having some issue operating on the cygXt-6.dll file.  Do you have 



write access to that file and its directory?


I do. Here we go (started from a non-X terminal):

admin@hostname:~$ xpdf

Cygwin runtime failure: /usr/bin/xpdf.exe: Invalid relocation.  Offset 
0x2f6e3bad9 at address 0x100494523 doesn't fit into 32 bits

admin@hostname:~$ ls -la /usr/bin/cygXt-6.dll

-rwxr-xr-x 1 admin None 333855 29. Jan 21:27 /usr/bin/cygXt-6.dll

admin@hostname:~$ ls -la /usr/

insgesamt 920

drwxr-xr-x+ 1 admin None 0 28. Nov 13:24 .

drwxr-xr-x+ 1 admin None 0 15. Aug 2015  ..

drwxr-xr-x+ 1 admin None 0 17. Apr 22:23 bin

...


As we see, the write attributes for "admin" are set, and I am "admin"
--
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: Formatting command line arguments when starting a Cygwin process from a native process

[Andrey Repin]

Greetings, David Allsopp!

> [With apologies if threading is broken; I erroneously thought as the list
> was not subscriber-only that replies would use reply-all and so wasn't 
> subscribed]

As long as your mail client is fine, you're fine.

> I'm not using cmd, or any shell for that matter (that's
> actually the point) - I am in a native Win32 process invoking a Cygwin
> process directly using the Windows API's CreateProcess call. As it happens,
> the program I have already has the arguments for the Cygwin process in an
> array, but Windows internally requires a single command line string (which
> is not in any related to Cmd).

Then all you need is a rudimentary quoting.
The rest will be handled by getopt when the command line is parsed.

>> However, I've found Windows's interpretation to be inconsistent, so often
>> have to play with it to find what the "right combination" is for a
>> particular instance.
>> 
>> I find echoing the parameters to a temporary text file and then using the
>> file as input to be more reliable and easier to troubleshoot, and it
>> breaks apart whether it is Windows cli inconsistencies or receiving
>> program issues very nicely with the text file content as an intermediary

> This is an OK tack, but I don't wish to do this by experimentation and get
> caught out later by a case I didn't think of, so what I'm trying to
> determine is *exactly* how the Cygwin DLL processes the command line via its
> source code so that I can present it with my argv array converted to a
> single command line and be certain that the Cygwin will recover the same argv 
> DLL.

> My reading of the relevant sources suggests that with globbing disabled,
> backslash escape sequences are *never* interpreted (since the quote function
> returns early - dcrt0.cc, line 171). If there is no way of encoding the
> double quote character, then perhaps I have to run with globbing enabled but
> ensure that the globify function will never actually expand anything - but
> as that's a lot of work, I was wondering if I was missing something with the 
> simpler "noglob" case.

The point being, when you pass the shell and enter direct process execution,
you don't need much of shell magic at all.
Shell conventions designed to ease interaction between system and operator.
But you have a system talking to the system, you can be very literal.


-- 
With best regards,
Andrey Repin
Friday, May 6, 2016 17:18:00

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

Re: Formatting command line arguments when starting a Cygwin process from a native process

[Erik Soderquist]

On Fri, May 6, 2016 at 4:03 AM, David Allsopp wrote:
>
> [With apologies if threading is broken; I erroneously thought as
> the list was not subscriber-only that replies would use reply-all
> and so wasn't subscribed]

Didn't break for me, though that might be google's threading in gmail
rather than standard threading.

> > C:\cygwin64\bin>.\echo.exe -e ^"hello\nworld^"
> > hello
> > world
> >
> > works.
>
> Indeed - but I'm not using cmd, or any shell for that matter
> (that's actually the point) - I am in a native Win32 process
> invoking a Cygwin process directly using the Windows API's
> CreateProcess call.  As it happens, the program I have already
> has the arguments for the Cygwin process in an array, but Windows
> internally requires a single command line string (which is not in
> any related to Cmd).

The you are way over my head...


> > However, I've found Windows's interpretation to be inconsistent, so often
> > have to play with it to find what the "right combination" is for a
> > particular instance.
> >
> > I find echoing the parameters to a temporary text file and then using the
> > file as input to be more reliable and easier to troubleshoot, and it
> > breaks apart whether it is Windows cli inconsistencies or receiving
> > program issues very nicely with the text file content as an intermediary
>
> This is an OK tack, but I don't wish to do this by experimentation
> and get caught out later by a case I didn't think of, so what I'm
> trying to determine is *exactly* how the Cygwin DLL processes the
> command line via its source code so that I can present it with my
> argv array converted to a single command line and be certain that
> the Cygwin will recover the same argv DLL.
>
> My reading of the relevant sources suggests that with globbing
> disabled, backslash escape sequences are *never* interpreted (since
> the quote function returns early - dcrt0.cc, line 171). If there is
> no way of encoding the double quote character, then perhaps I have
> to run with globbing enabled but ensure that the globify function
> will never actually expand anything - but as that's a lot of work,
> I was wondering if I was missing something with the simpler
> "noglob" case.

Again, way over my head, I'm currently a shell scripter...

-- Erik

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

[ITP] python-configobj 5.0.6 (4.7.2 is in Cygwin Ports)

[Mike DePaulo]

This package is currently in Cygwin Ports at version 4.7.2-2, as well
as in major distros like Fedora & Debian.

The 5.0.x series has a new upstream. They also removed the PKG-INFO file.

It is a dependency of package terminator, which is currently in an ITP
state from Cygwin Ports also.

https://github.com/mikedep333/python-configobj-cygport

category: Python
requires: python python-six
sdesc: "Python module for handling config files"
ldesc: "ConfigObj is a simple but powerful config file reader and writer:
an ini file round tripper. Its main feature is that it is very easy to use,
with a straightforward programmer's interface and a simple syntax for config
files."

cmp missing from base

[Thomas Wolff]

Hi,
after a recent fresh installation of cygwin, I was surprised that `cmp` 
was missing, which is part of the traditional Unix base commands.

I think the diffutils package should be part of the base installation.
Kind regards,
Thomas

RE: Formatting command line arguments when starting a Cygwin process from a native process

[David Allsopp]

[With apologies if threading is broken; I erroneously thought as the list was 
not subscriber-only that replies would use reply-all and so wasn't subscribed]

On Thu, May 5, 2016 at 06:47 PM, Erik Soderquist wrote:
> On Thu, May 5, 2016 at 11:24 AM, David Allsopp wrote:
> >
> > I am trying to work out the precise details for character escaping
> > when starting a Cygwin process from a native (i.e. non-Cygwin) Windows
> process.
> 
> > For example:
> >
> >   argv[0] = "foo"
> >   argv[1] = "bar baz"
> >
> > then the resulting command line string should be:
> >
> >   lpCommandLine = "foo bar\" \"baz"
> 
> If I recall correctly, Windows cmd.exe uses the carrot (^) as the general
> escape from shell character, so
> 
> C:\cygwin64\bin>.\echo.exe -e ^"hello\nworld^"
> hello
> world
> 
> works.

Indeed - but I'm not using cmd, or any shell for that matter (that's actually 
the point) - I am in a native Win32 process invoking a Cygwin process directly 
using the Windows API's CreateProcess call. As it happens, the program I have 
already has the arguments for the Cygwin process in an array, but Windows 
internally requires a single command line string (which is not in any related 
to Cmd).

> However, I've found Windows's interpretation to be inconsistent, so often
> have to play with it to find what the "right combination" is for a
> particular instance.
> 
> I find echoing the parameters to a temporary text file and then using the
> file as input to be more reliable and easier to troubleshoot, and it
> breaks apart whether it is Windows cli inconsistencies or receiving
> program issues very nicely with the text file content as an intermediary

This is an OK tack, but I don't wish to do this by experimentation and get 
caught out later by a case I didn't think of, so what I'm trying to determine 
is *exactly* how the Cygwin DLL processes the command line via its source code 
so that I can present it with my argv array converted to a single command line 
and be certain that the Cygwin will recover the same argv DLL.

My reading of the relevant sources suggests that with globbing disabled, 
backslash escape sequences are *never* interpreted (since the quote function 
returns early - dcrt0.cc, line 171). If there is no way of encoding the double 
quote character, then perhaps I have to run with globbing enabled but ensure 
that the globify function will never actually expand anything - but as that's a 
lot of work, I was wondering if I was missing something with the simpler 
"noglob" case.


David


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

[ANNOUNCEMENT] gnome2048 3.18.2-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gnome2048-3.18.2-1

GNOME 2048 is a clone of Gabriele Cirulli's 2048 sliding tile game.

--
Yaakov

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

gnome2048 3.18.2-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gnome2048-3.18.2-1

GNOME 2048 is a clone of Gabriele Cirulli's 2048 sliding tile game.

--
Yaakov

[ANNOUNCEMENT] 2048-qt 0.1.6-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* 2048-qt-0.1.6-1

A clone of 2048 and variants, implemented in Qt.

--
Yaakov

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

2048-qt 0.1.6-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* 2048-qt-0.1.6-1

A clone of 2048 and variants, implemented in Qt.

--
Yaakov

[ANNOUNCEMENT] 2048-cli 0.9.1-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* 2048-cli-0.9.1-1

A CLI version/engine of the game 2048 for the *NIX terminal.

--
Yaakov

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

2048-cli 0.9.1-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* 2048-cli-0.9.1-1

A CLI version/engine of the game 2048 for the *NIX terminal.

--
Yaakov