[PATCH] Fix optional variables in libargp

[Fedin Pavel]

 Hello!

> Okay, well I agree that this sounds like a good solution.  For now you
> have a workaround, and I'll be glad to consider a patch if you submit
> one.

 Please take it. This is my experimental implementation which appears to be
simpler than i suggested.

 Some details: this implementation adds explicit dllexport attribute to
these 4 variables. This allows to look them up using GetProcAddress(). The
dllexport attribute has to be added explicitly because when compiling an
.exe file (without -shared switch) gcc does not mark externals as exportable
by default. When building a .dll, all external symbols are marked as
exportable by default, *UNLESS* we have at least one explicit dllexport
specification, hence i surrounded this with #ifndef DLL_EXPORT, this
definition is introduced by libtool when building a shared library.
 This implementation would not work in the following corner cases:
 a) .exe file uses some foo.dll library, which defines these variables and
uses libargp - symbols are picked up only from .exe file itself.
 b) Building that foo.dll manually without DLL_EXPORT definition can get
broken - the compiler will see dllexport attribute, and it will override the
default behavior to make all externs exportable.
 I believe these cases are quite unusual so it's OK. Getting rid of these
limitations would need more complex implementation with more changes.

 I have tested the implementation on x86-64 with RedHat's Prelink utility,
and it works quite fine. i386 should work too, but please retest, just in
case.

 Additionally, i added the second #ifdef _WIN32 in order to make the same
thing working also for MinGW target.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


libargp-20110921-fix-optional-variables.diff
Description: Binary data
--
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: Recent Cygwin problems

[Gary Johnson]

On 2013-06-21, Gary Johnson wrote:
> I've had Cygwin installed on this computer for over two years
> without any problems but recently I've started seeing a few problems
> and my installation seems corrupted.
> 
> 1.  Starting several weeks ago, whenever I run setup.exe I get this
> pop-up message part way through the process.
> 
> Cygwin Setup - Running postinstall scripts
> 
> Postinstall script errors
> These do not necessarily mean that affected packages
> will fail to function properly, but please check
> /var/log/setup.log.full and report any problems.
> 
> Package: Unknown package
>  pango1.0.sh exit code 1
> 
> The relevant lines from /var/log/setup.log.full (following a
> reinstall of the mutt package) seem to be these at the end:
> 
> 2013/06/21 10:05:29 running: C:\cygwin\bin\bash.exe --norc 
> --noprofile "/etc/postinstall/mutt.sh"
> 2013/06/21 10:05:30 running: C:\cygwin\bin\bash.exe --norc 
> --noprofile "/etc/postinstall/pango1.0.sh"
> /etc/postinstall/pango1.0.sh: line 1: /etc/pango/pango.modules: No 
> such file or directory
> 2013/06/21 10:05:30 abnormal exit: exit code=1
> 2013/06/21 10:05:30 Changing gid to Administrators
> 2013/06/21 10:07:23 note: Installation Complete
> 2013/06/21 10:07:23 Ending cygwin install

I looked further into this one and figured it out.  Line 1 of
/etc/postinstall/pango1.0.sh is

/usr/bin/pango-querymodules > /etc/pango/pango.modules

but there was no /etc/pango directory.  That was apparently what the
message

/etc/pango/pango.modules: No such file or directory

was trying to say.  I just created that directory and now
installations from setup.exe complete without that pop-up message.

Regards,
Gary


--
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: How does 'alternatives' find a file?

[Charles Wilson]

On 7/16/2013 4:11 PM, Larry Hall (Cygwin) wrote:

On 7/16/2013 2:46 PM, Henry Baker wrote:

I've had to create a cygwin tree from a circa 2011 tar dump, and I've
had  a devil of a time trying to make it work.

Looking at the ones I have in /etc/alternatives, they are the first kind
listed (or the ones that you say work for you).  Make sure the DOS SYSTEM
attribute (and only that attribute) is set.  Also, if the tree doesn't
come from Cygwin 1.7 days and you're not using the same character set as
you were then, you'll need to recreate the symlinks to get them working
again.


Just use the alternatives tool itself to forcefully recreate the 
symlinks -- in fact, there's a script that will do that for you. Look in 
/etc/postinstall/ for the files that have "gcc" somewhere in their name. 
Find the ones that invoke /usr/sbin/alternatives and run the appropriate 
ones (whichever ones set the default to gcc4 rather than gcc3).


--
Chuck


--
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: mingw.org cross compiler [Was: problem with cvs binary?]

[Charles Wilson]

On 7/16/2013 12:25 PM, Earnie Boyd wrote:

On Tue, Jul 16, 2013 at 11:39 AM, Charles Wilson wrote:

least want to update our current offering to something more current than
4.5.x, AND it's necessary on i686 because recent gmp/mpfr/mpc library
updates have broken mingw-gcc.  If, after this update, we want to declare
EOL on mingw(.org)-gcc, we could discuss that on cygwin-apps.


Can you specify what the issues are for gmp/mpfr/mpc?  I ask because
I'm attempting to build 2.8.1.


It's just that from what I can tell, cygmpc-1.dll is no longer available 
from any package. So I want to rebuild the compiler to link against 
cygmpc-3.dll.


http://cygwin.com/ml/cygwin-apps/2013-07/msg00029.html

--
Chuck





--
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: How does 'alternatives' find a file?

[Larry Hall (Cygwin)]

On 7/16/2013 2:46 PM, Henry Baker wrote:

I've had to create a cygwin tree from a circa 2011 tar dump, and I've
had  a devil of a time trying to make it work.

The biggest problem I have right now is that 'alternatives'-style
symlinks  don't work.

(The "!"-style symlinks _do_ seem to work.)


Here's the page from the Users Guide with the information about the
different kind of symlinks:



Looking at the ones I have in /etc/alternatives, they are the first kind
listed (or the ones that you say work for you).  Make sure the DOS SYSTEM
attribute (and only that attribute) is set.  Also, if the tree doesn't
come from Cygwin 1.7 days and you're not using the same character set as
you were then, you'll need to recreate the symlinks to get them working
again.

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

How does 'alternatives' find a file?

[Henry Baker]

I've had to create a cygwin tree from a circa 2011 tar dump, and I've had a 
devil of a time trying to make it work.

The biggest problem I have right now is that 'alternatives'-style symlinks 
don't work.

(The "!"-style symlinks _do_ seem to work.)

After doing a lot of Google searching, I tried various combinations of

attrib +s gcc.exe

attrib +r gcc.exe

etc., to no avail.

I can make gcc.exe work by forcibly copying gcc-4.exe to gcc.exe, but there are 
probably thousands of such links that
would have to be set manually.

The best thing would be to understand how 'alternatives' finds its files, and 
fix that to correctly find all of the files.

I'm running from both NTFS and FAT32 file systems; neither one works.

I'm running Windows 7 on a 64-bit machine, if that matters.

Thanks for any help; I've now spent many hours trying to solve this problem.


--
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] New package: poco-1.4.6p1-1

[David Stacey]

The following packages have been added to Cygwin:

  - poco-1.4.6p1-1
  - libpoco-devel-1.4.6p1-1
  - libpoco-doc-1.4.6p1-1
  - libpoco16-1.4.6p1-1
  - poco-debuginfo-1.4.6p1-1


DESCRIPTION
===

Poco is a collection of modern, powerful open source C++ class libraries and
frameworks for building network- and internet-based applications that run on
desktop, server, mobile and embedded systems. They simplify and accelerate
the development of network-centric, portable applications in C++.


CHANGE LOG
==

https://raw.github.com/pocoproject/poco/poco-1.4.6/CHANGELOG

Release 1.4.6p1 (2013-03-06)
- fixed GH# 71: WebSocket and broken Timeouts (POCO_BROKEN_TIMEOUTS)
- fixed an ambiguity error with VC++ 2010 in Data/MySQL testsuite
- Poco::Net::NetworkInterface now provides the interface index even for IPv4
- added DNS::reload() as a wrapper for res_init().
- On Linux, Poco::Environment::nodeId() first always tries to obtain the
  MAC address of eth0, before looking for other interfaces.
- Poco::Net::HTTPSession now always resets the buffer in connect() to clear
  any leftover data from a (failed) previous session
- fixed copysign namespace issue in FPEnvironment_DUMMY.h
- fixed a warning in Poco/Crypto/OpenSSLInitializer.h
- added a build configuration for BeagleBoard/Angstrom
- fixed GH# 109: Bug in Poco::Net::SMTPClientSession::loginUsingPlain)
- fixed compile errors with clang -std=c++11
- fixed GH# 116: Wrong timezone parsing in DateTimeParse (fix by Matej 
Knopp)

- updated bundled SQLite to 3.7.15.2


HOMEPAGE


http://pocoproject.org/


Cheers,

Dave.



If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in
the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.

--
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: bzr problem

[Achim Gratz]

Katsumi Yamaoka writes:
> BTW, when I run `bzr update' for the Emacs trunk, it shows a warning
> that varies like:
>
> 0 [main] python2.7 1300 child_info_fork::abort: unable to remap\
> _ARC4.dll to same address as parent (0xBE) - try running rebaseall
> 0 [main] python2.7 4180 child_info_fork::abort: address space needed by\
>  '_socket.dll' (0x86) is already occupied
> 0 [main] python2.7 8072 child_info_fork::abort: address space needed by\
>  'operator.dll' (0x3D) is already occupied

What apparently happens is that the DLL gets originally loaded onto a
low address, presumably due to something intercepting the loader, then
when the process forks that address is already in use so the DLL can't
be mapped to that address in the process image.  This has all the
fingerprints of a "real-time" / behavioural virus scanner, so you might
want to investigate whether you can exclude the Cygwin install folder
from this.  If that's not possible to set up, you can sometimes move the
Cygwin installation into a directory tree that already is excluded
(often %PROGRAMFILES% is treated differently than other tress, etc.).

> rebaseall_log.txt shows that those DLLs were rebased into:
>
> /usr/lib/python2.7/site-packages/Crypto/Cipher/_ARC4.dll:\
>  new base = 36df, new size = 1
> /usr/lib/python2.7/lib-dynload/_socket.dll:\
>  new base = 3717, new size = 2
> /usr/lib/python2.7/lib-dynload/operator.dll:\
>  new base = 36f9, new size = 1
>
> As for "_ARC4.dll", how does "36df" mean "0xBE"?

Not at all: the DLL simply doesn't get loaded where it has been rebased
to.


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

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


--
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: Issue with run.exe and PWD with spaces since last update (Cygwin 1.7.21)

[Andrey Repin]

Greetings, All!

> I'm trying to execute a script that was working fine until recent update.
> It doesn't crash, just, for some reason, trim the last component of a path.

Sorry, it doesn't "trim" anything. The line was from earlier guess, before I
started to run more tests.

> In a nutshell, the issue is this:

> $ mkdir "/a b"
> $ cd "/a b"
> $ ls -l "$SYSTEMROOT/System32/notepad.exe"
> (just to confirm that the file actually exists)
> $ run "$SYSTEMROOT/System32/notepad.exe"
> Error pops up:

> ---
> Run.exe
> ---
> Error: could not start C:\Programs\CygWin\a b

> ---
> OK
> ---


> $ cygcheck.exe -f /bin/run.exe
> run-1.2.0-1

> $ cygcheck.exe -c run
> Cygwin Package Information
> Package  VersionStatus
> run  1.2.0-1OK

Reverting to previous version of package doesn't help.


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 16.07.2013, <21:02>

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

Issue with run.exe and PWD with spaces since last update (Cygwin 1.7.21)

[Andrey Repin]

Greetings, All!

I'm trying to execute a script that was working fine until recent update.
It doesn't crash, just, for some reason, trim the last component of a path.

In a nutshell, the issue is this:

$ mkdir "/a b"
$ cd "/a b"
$ ls -l "$SYSTEMROOT/System32/notepad.exe"
(just to confirm that the file actually exists)
$ run "$SYSTEMROOT/System32/notepad.exe"
Error pops up:

---
Run.exe
---
Error: could not start C:\Programs\CygWin\a b

---
OK
---


$ cygcheck.exe -v run
Found: C:\Programs\CygWin\bin\run.exe
Found: C:\Programs\CygWin\bin\run.exe
C:\Programs\CygWin\bin\run.exe - os=4.0 img=1.0 sys=4.0
  C:\Programs\CygWin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2013-07-15 11:17
C:\WINDOWS\system32\KERNEL32.dll - os=5.1 img=5.1 sys=4.0
  "KERNEL32.dll" v0.0 ts=2009-03-21 12:36
  C:\WINDOWS\system32\ntdll.dll - os=5.1 img=5.1 sys=4.10
"ntdll.dll" v0.0 ts=2010-12-09 13:38
C:\WINDOWS\system32\ntdll.dll (already done)
  C:\WINDOWS\system32\KERNEL32.dll (already done)
  C:\WINDOWS\system32\SHELL32.DLL - os=5.1 img=5.1 sys=4.10
"SHELL32.dll" v0.0 ts=2012-06-08 14:41
C:\WINDOWS\system32\ADVAPI32.dll - os=5.1 img=5.1 sys=4.0
  "ADVAPI32.dll" v0.0 ts=2009-02-06 11:02
  C:\WINDOWS\system32\KERNEL32.dll (already done)
  C:\WINDOWS\system32\ntdll.dll (already done)
  C:\WINDOWS\system32\RPCRT4.dll - os=5.1 img=5.1 sys=4.10
"RPCRT4.dll" v0.0 ts=2010-08-13 14:32
C:\WINDOWS\system32\ADVAPI32.dll (recursive)
C:\WINDOWS\system32\KERNEL32.dll (already done)
C:\WINDOWS\system32\ntdll.dll (already done)
C:\WINDOWS\system32\Secur32.dll - os=5.1 img=5.1 sys=4.0
  "Secur32.dll" v0.0 ts=2009-06-24 13:10
  C:\WINDOWS\system32\ADVAPI32.dll (recursive)
  C:\WINDOWS\system32\KERNEL32.dll (already done)
  C:\WINDOWS\system32\ntdll.dll (already done)
C:\WINDOWS\system32\GDI32.dll - os=5.1 img=5.1 sys=4.10
  "GDI32.dll" v0.0 ts=2008-10-22 17:52
  C:\WINDOWS\system32\KERNEL32.dll (already done)
  C:\WINDOWS\system32\ntdll.dll (already done)
  C:\WINDOWS\system32\USER32.dll - os=5.1 img=5.1 sys=4.0
"USER32.dll" v0.0 ts=2008-04-13 20:22
C:\WINDOWS\system32\GDI32.dll (recursive)
C:\WINDOWS\system32\KERNEL32.dll (already done)
C:\WINDOWS\system32\ntdll.dll (already done)
C:\WINDOWS\system32\KERNEL32.dll (already done)
C:\WINDOWS\system32\msvcrt.dll - os=5.1 img=5.1 sys=4.0
  "msvcrt.dll" v0.0 ts=2008-04-13 17:41
  C:\WINDOWS\system32\KERNEL32.dll (already done)
  C:\WINDOWS\system32\ntdll.dll (already done)
C:\WINDOWS\system32\ntdll.dll (already done)
C:\WINDOWS\system32\RPCRT4.dll (already done)
C:\WINDOWS\system32\SHLWAPI.dll - os=5.1 img=5.1 sys=4.0
  "SHLWAPI.dll" v0.0 ts=2009-12-07 13:39
  C:\WINDOWS\system32\ADVAPI32.dll (already done)
  C:\WINDOWS\system32\GDI32.dll (already done)
  C:\WINDOWS\system32\KERNEL32.dll (already done)
  C:\WINDOWS\system32\msvcrt.dll (already done)
  C:\WINDOWS\system32\USER32.dll (already done)
C:\WINDOWS\system32\USER32.dll (already done)
  C:\WINDOWS\system32\USER32.dll (already done)

$ cygcheck.exe -f /bin/run.exe
run-1.2.0-1

$ cygcheck.exe -c run
Cygwin Package Information
Package  VersionStatus
run  1.2.0-1OK


-- 
WBR,
Andrey Repin (anrdae...@freemail.ru) 16.07.2013, <20:12>

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: mingw.org cross compiler [Was: problem with cvs binary?]

[Earnie Boyd]

On Tue, Jul 16, 2013 at 11:39 AM, Charles Wilson wrote:
> On 7/16/2013 9:10 AM, Corinna Vinschen wrote:
>>
>> Are the mingw cross compilers still necessary, now that we have
>> modern mingw-w64 toolchains?  On Fedora they aren't shipped since
>> F17, which already came with mingw-w64 toolchains either.
>
>
> No, in the sense that you could use the mingw-w64 i686 toolchain to generate
> 32bit "native" windows apps instead.
>
> Yes, because the two toolchains are not mutually compatible (different ABI,
> different exception model, different threading library, different
> w32api/runtime library). If you are using a cygwin $host to develop,
> specifically, mingw.org-distribution compatible apps/libs...then you need
> the mingw.org cross compiler.
>
> I don't know how many people that represents -- it might just be me and
> Earnie -- but I'm not ready to declare mingw(.org)-gcc dead just yet.  I at

I'm not actually using mingw-gcc on Cygwin and have no opinion for the offering.

> least want to update our current offering to something more current than
> 4.5.x, AND it's necessary on i686 because recent gmp/mpfr/mpc library
> updates have broken mingw-gcc.  If, after this update, we want to declare
> EOL on mingw(.org)-gcc, we could discuss that on cygwin-apps.

Can you specify what the issues are for gmp/mpfr/mpc?  I ask because
I'm attempting to build 2.8.1.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: [ANNOUNCEMENT] Updated: run2-0.4.2-1

[K Stahl]

Sorry, my first message got lost in the mailer.

Basically, I updated today and noticed that checkX segfaults (see attachment).
I've tried both the latest and previous versions, and they both fail now.

Any help would be appreciated.




On Tue, Jul 16, 2013 at 11:45 AM, K Stahl  wrote:
> Just reverted the run2 package to 0.4.0-1 and checkX still segfaults.
>
> Attached is the output of cygcheck (for reference)


checkX.exe.stackdump
Description: Binary data
--
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

mingw.org cross compiler [Was: problem with cvs binary?]

[Charles Wilson]

On 7/16/2013 9:10 AM, Corinna Vinschen wrote:

Are the mingw cross compilers still necessary, now that we have
modern mingw-w64 toolchains?  On Fedora they aren't shipped since
F17, which already came with mingw-w64 toolchains either.


No, in the sense that you could use the mingw-w64 i686 toolchain to 
generate 32bit "native" windows apps instead.


Yes, because the two toolchains are not mutually compatible (different 
ABI, different exception model, different threading library, different 
w32api/runtime library). If you are using a cygwin $host to develop, 
specifically, mingw.org-distribution compatible apps/libs...then you 
need the mingw.org cross compiler.


I don't know how many people that represents -- it might just be me and 
Earnie -- but I'm not ready to declare mingw(.org)-gcc dead just yet.  I 
at least want to update our current offering to something more current 
than 4.5.x, AND it's necessary on i686 because recent gmp/mpfr/mpc 
library updates have broken mingw-gcc.  If, after this update, we want 
to declare EOL on mingw(.org)-gcc, we could discuss that on cygwin-apps.


--
Chuck


--
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: Cygwin, python and abspath()

[Mikko Rapeli]

On Tue, Jul 16, 2013 at 06:01:06PM +0300, Mikko Rapeli wrote:
> Hi,
> 
> Does anyone know why os.path.abspath() in python on cygwin is creating
> invalid path names when given these cygwin compatible dos path names?
> 
> $ pwd
> /cygdrive/c/temp
> 
> $ python -c "import os; os.path.abspath('/cygdrive/c/temp')"
> /cygdrive/c/temp
> 
> $ python -c "import os; os.path.abspath('c:/temp')"
> /cygdrive/c/temp/c:/temp
> 
> I have cmake generating the dos compatible path names and they work with
> all other cygwin utilities that I've used.

Perl seems to understand both ways as absolute paths:

$ perl -e 'use File::Spec; print File::Spec->rel2abs("c:/temp")'
c:/temp

$ perl -e 'use File::Spec; print File::Spec->rel2abs("/cygdrive/c/temp")'
/cygdrive/bin/perl

$ which perl
/usr/bin/perl

$ perl --version | head -2 | tail -1
This is perl 5, version 14, subversion 2 (v5.14.2) built for 
cygwin-thread-multi-64int

-Mikko

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

Cygwin, python and abspath()

[Mikko Rapeli]

Hi,

Does anyone know why os.path.abspath() in python on cygwin is creating
invalid path names when given these cygwin compatible dos path names?

$ pwd
/cygdrive/c/temp

$ python -c "import os; os.path.abspath('/cygdrive/c/temp')"
/cygdrive/c/temp

$ python -c "import os; os.path.abspath('c:/temp')"
/cygdrive/c/temp/c:/temp

I have cmake generating the dos compatible path names and they work with
all other cygwin utilities that I've used.

And wouldn't it be nice if cygwin would not allow creating files and
directories named "c:"...

-Mikko

--
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: During postinstall, warning: Package: Unknown package; a2ps.sh exit code 2

[Kyle Skrinak]

Ken,

It's a bug. I'm unclear how to report it to the cygwin maintainer, but I found 
a workaround over on an ubuntu bug tracker: 
https://bugs.launchpad.net/ubuntu/+source/a2ps/+bug/149551 It's a very simple 
fix:

echo "letter" > /etc/papersize

in your cygwin terminal. I reran setup.exe without error afterwards.

Kyle


--
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: problem with cvs binary?

[Corinna Vinschen]

On Jul 16 09:07, Charles Wilson wrote:
> On 7/15/2013 11:21 PM, Mark Levedahl wrote:
> >The currently provided cvs executable does not work correctly, simple
> >test case is:
> >
> >~>export CVSROOT=/tmp/cvsroot
> >~>cvs init
> >~>cvs co -d /tmp/workdir .
> >cvs [checkout aborted]: cannot make directory : No such file or directory
> >
> >~>cygcheck -c cvs
> >Cygwin Package Information
> >Package  VersionStatus
> >cvs  1.12.13-10 OK
> >
> >~>uname -a
> >CYGWIN_NT-5.1 virt-winxp 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin
> >
> >The above should checkout the empty project to /tmp/workdir, but does
> >not work with the binary provided via setup.exe. This does work
> >correctly with a) cvs-1.12.13 rebuilt from sources, and b) with cvs v
> >1.11.22-1 downloaded from setup.exe. The expected result:
> 
> Thanks for the report. Rebuilding cvs against current 32bit
> w32api/cygwin is on my list, as well updating the 64bit package.
> However, it comes after (a) mingw-gcc cross compiler & friends, (b)
> automake-X.Y, and (c) libtool. :-(

Are the mingw cross compilers still necessary, now that we have
modern mingw-w64 toolchains?  On Fedora they aren't shipped since
F17, which already came with mingw-w64 toolchains either.


Corinna

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

--
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: problem with cvs binary?

[Charles Wilson]

On 7/15/2013 11:21 PM, Mark Levedahl wrote:

The currently provided cvs executable does not work correctly, simple
test case is:

~>export CVSROOT=/tmp/cvsroot
~>cvs init
~>cvs co -d /tmp/workdir .
cvs [checkout aborted]: cannot make directory : No such file or directory

~>cygcheck -c cvs
Cygwin Package Information
Package  VersionStatus
cvs  1.12.13-10 OK

~>uname -a
CYGWIN_NT-5.1 virt-winxp 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin

The above should checkout the empty project to /tmp/workdir, but does
not work with the binary provided via setup.exe. This does work
correctly with a) cvs-1.12.13 rebuilt from sources, and b) with cvs v
1.11.22-1 downloaded from setup.exe. The expected result:


Thanks for the report. Rebuilding cvs against current 32bit 
w32api/cygwin is on my list, as well updating the 64bit package. 
However, it comes after (a) mingw-gcc cross compiler & friends, (b) 
automake-X.Y, and (c) libtool. :-(


--
Chuck




--
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: 64-bit NFS

[Fedin Pavel]

 Hello!

> >  Is anybody interested in these patches? Unfortunately i can't take
> > over regular nfs-server maintenance.
> 
> Why not?  You seem to be the right person for this.

 Because of time lack.
 BTW, who is original author of our Universal NFS Server ? I think some of 
patches should go directly there, but don't know who is project owner, and 
failed to google up any homepage.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: 64-bit NFS

[Corinna Vinschen]

On Jul 16 14:48, Fedin Pavel wrote:
>  Hello!
> 
>  Is there any particular reason why NFS server is missing in 64-bit version
> ?
>  I heard nfs-server package is not maintained any more. If anybody is
> interested, i have patched my 32-bit NFS server, and in order to do this i
> had to do the following face-lift tomy Cygwin installation:
> 1. Fix the NFS server code in order to build with new TI-RPC.
> 2. Replace portmap with rpcbind (advanced version of portmapper written
> specifically for TI-RPC).
> 
>  Is anybody interested in these patches? Unfortunately i can't take over
> regular nfs-server maintenance.

Why not?  You seem to be the right person for this.


Corinna

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

--
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: ctrl-c to windows program causes mintty to hang [1.7.20 / win7]

[Marvin]

Pretty awesome!

Works like a charm!




--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/ctrl-c-to-windows-program-causes-mintty-to-hang-1-7-20-win7-tp99346p100846.html
Sent from the Cygwin list mailing list archive at Nabble.com.

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

64-bit NFS

[Fedin Pavel]

 Hello!

 Is there any particular reason why NFS server is missing in 64-bit version
?
 I heard nfs-server package is not maintained any more. If anybody is
interested, i have patched my 32-bit NFS server, and in order to do this i
had to do the following face-lift tomy Cygwin installation:
1. Fix the NFS server code in order to build with new TI-RPC.
2. Replace portmap with rpcbind (advanced version of portmapper written
specifically for TI-RPC).

 Is anybody interested in these patches? Unfortunately i can't take over
regular nfs-server maintenance.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia




--
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: bzr problem

[Katsumi Yamaoka]

Achim Gratz wrote:
> Katsumi Yamaoka writes:
>>> I'd venture to guess that the DLL(s) in question belong to a Python
>>> package.  If so, does the rebaseall script you are using look at those
>>> libraries at all?
>>
>> As far as I can observe, those DLLs are listed in TEMP/rebase.lst
>> (that rebaseall temporarily generates), and `rebaseall -v' shows
>> that they are processed by `rebase'.  Thanks.

> You could dump the contents of the rebase database then and check what
> the base address for this library is supposed to be.  Chances are that
> it is very much higher than what your example of a fork fail shows.  In
> my experience, such low base addresses indicate BLODA; however if a
> library is indeed rebased into this region it has almost zero chances of
> correctly forking in that address range.

Sorry, I don't know what the proper base address is, how it is
decided, nor what a value causes.  If possible, could you spend
a little time to look into the rebaseall log I made?  Here it is:

http://www.jpl.org/tmp/rebaseall_log.txt

At that time, I ran `rebaseall -v' and verified it ran `rebase'
as follows:

rebase -v -n -s -4\
 -T /cygdrive/c/Users/yamaoka/AppData/Local/Temp/rebase.lst

BTW, when I run `bzr update' for the Emacs trunk, it shows a warning
that varies like:

0 [main] python2.7 1300 child_info_fork::abort: unable to remap\
_ARC4.dll to same address as parent (0xBE) - try running rebaseall
0 [main] python2.7 4180 child_info_fork::abort: address space needed by\
 '_socket.dll' (0x86) is already occupied
0 [main] python2.7 8072 child_info_fork::abort: address space needed by\
 'operator.dll' (0x3D) is already occupied

rebaseall_log.txt shows that those DLLs were rebased into:

/usr/lib/python2.7/site-packages/Crypto/Cipher/_ARC4.dll:\
 new base = 36df, new size = 1
/usr/lib/python2.7/lib-dynload/_socket.dll:\
 new base = 3717, new size = 2
/usr/lib/python2.7/lib-dynload/operator.dll:\
 new base = 36f9, new size = 1

As for "_ARC4.dll", how does "36df" mean "0xBE"?

Thanks in advance.
Regards,

P.S. I tried running rebaseall also for some files I installed in
/usr/local, but it didn't help.  What I did then was:

--- rebaseall~  2013-01-16 16:36:08.0 +
+++ rebaseall   2013-07-16 09:47:40.982715800 +
@@ -221,6 +221,8 @@
 ;;
 esac
 
+find /usr/local -regex '.+\.\(dll\|so\|oct\)$' >> "$TmpFile"
+
 # Append user supplied file list, if any
 if [ -n "${FileList}" ]
 then


--
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: SVN::Ra problems

[Mikko Rapeli]

> >> cygcheck output from the working setup is:
> >> Found: C:\cygwin\bin\perl.exe
> >> Found: C:\Testwell\CTC\perl
> >> Warning: C:\cygwin\bin\perl.exe hides C:\Testwell\CTC\perl
>
> > I wonder if this is the reason? Perhaps Cygwin was picking up the wrong
> > perl?
> 
> Without any "perhaps".

Yes! This was the problem. Damn these multiple copies.

Now I know to read cygcheck output in detail. Thanks!

-Mikko

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

libdb4.8-devel.sh exits with errorlevel=2

[Andrey Repin]

Greetings, All!

Relevant lines from setup.log.full:

2013/07/16 10:52:34 running: C:\Programs\CygWin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/libdb4.8-devel.sh"
admindir /var/lib/alternatives invalid
admindir /var/lib/alternatives invalid
2013/07/16 10:52:34 abnormal exit: exit code=2

This was update of existing installation on 32-bit system.


-- 
WBR,
Andrey Repin (anrdae...@freemail.ru) 16.07.2013, <10:57>

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