Re: [ITP] mp3info-0.8.5a

2014-05-29 Thread Yaakov (Cygwin/X)

On 2014-05-28 18:26, Filipp Gunbin wrote:

I'd like to maintain mp3info for Cygwin.  It does not have a good build
system, but it's simple and I somewhat managed it to work.  Besides
using it as a standalone utility, it can be used in Emacs EMMS (that's
in fact is why I need it).


Sorry; our policy is to not include MP3 software in the distribution, so 
unfortunately this package cannot be accepted.


I hope you will still consider becoming a maintainer for another 
package.  There are always packages needing new maintainers; these are 
marked as ORPHANED here:


https://cygwin.com/cygwin-pkg-maint


Yaakov



Re: [ITP] mp3info-0.8.5a

2014-05-29 Thread Filipp Gunbin
On 29/05/2014 21:26 +0400, Yaakov (Cygwin/X) wrote:

 On 2014-05-28 18:26, Filipp Gunbin wrote:
 I'd like to maintain mp3info for Cygwin.  It does not have a good build
 system, but it's simple and I somewhat managed it to work.  Besides
 using it as a standalone utility, it can be used in Emacs EMMS (that's
 in fact is why I need it).

 Sorry; our policy is to not include MP3 software in the distribution,
 so unfortunately this package cannot be accepted.

 I hope you will still consider becoming a maintainer for another
 package.  There are always packages needing new maintainers; these are
 marked as ORPHANED here:

 https://cygwin.com/cygwin-pkg-maint


 Yaakov

That's a pity!  No need to say what a huge amount of music is
distributed in mp3 nowadays (that's a pity, too).

Anyway, thanks.

Filipp


Re: [ITP] mp3info-0.8.5a

2014-05-29 Thread David Stacey

On 29/05/14 18:26, Yaakov (Cygwin/X) wrote:
Sorry; our policy is to not include MP3 software in the distribution, 
so unfortunately this package cannot be accepted.


Could you possibly elaborate on this please, as I wasn't aware of this 
policy. I presume that it's something like licence issues (not free as 
in freedom) or the risk of patent violation surrounding MP3.


I ask because a little while ago I managed to put a typo in a tag of a 
number of MP4 files, and corrected these by building AtomicParsley [1] 
for Cygwin. I had intended to offer it here, in case someone else found 
it useful. If AtomicParsley falls under the same policy then that's 
fine; I'll strike it off my list of things to do.


Thanks in advance for clarifying,

Dave.

[1] http://atomicparsley.sourceforge.net/



[MailServer Notification]Security Notification

2014-05-29 Thread PhoebeAdministrator
WORM_MYDOOM.GEN has been detected,and Clean fail, quarantine entire message has 
been taken on 29/May/2014 9:30:25.

--
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: Building cpan module that links with proprietary libs

2014-05-29 Thread Csaba Raduly
Hi Andrew,

On Thu, May 29, 2014 at 4:12 AM, Andrew DeFaria  wrote:
 I'm attempting to build a cpan module (well actually it's not a cpan module
 but rather a module that uses MakeMaker and has the familiar perl
 Makefile.PL, make, make test, make install installation procedure.
 Additionally I need to link it to a set of proprietary libs that I am given
 only the .lib files for. If you must know this is for Perforce's P4Perl
 which I'd like to get working with Cygwin's Perl natively.

 I download the P4API bundle (the package that has include files and the .lib
 files pre-compiled).

The C++ P4 API is platform-specific; which platform did you choose?
If it really contains .lib files (not .a), those are not recognized by
Cygwin's gcc.

 Next I need to do:

 $ perl Makefile.PL --api-dir /.../path/to/unzipped/p4api

 This works fine and I procedure with the make. This fails with things like:

 make[1]: Leaving directory '/cygdrive/a/perl/P4Perl.Cygwin/lib'
 g++ -c  -I/cygdrive/a/perl/p4api.windows/include/p4 -Ilib -x c++
 -DUSEIMPORTLIB -O3   -DVERSION=\2014.1\ -DXS_VERSION=\2014.1\
 -I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE
 -DID_OS=\CYGWIN17THREAD\ -DID_REL=\2014.1\ -DID_PATCH=\842847\
 -DID_Y=\2014\ -DID_M=\05\ -DID_D=\06\ -DOS_CYGWIN -DOS_CYGWIN17
 -DOS_CYGWIN17THREAD -DOS_CYGWINTHREAD -DP4API_VERSION=515585
 -DID_API=\2014.1/821990\ P4.c
 Running Mkbootstrap for P4 ()
 chmod 644 P4.bs
 rm -f blib/arch/auto/P4/P4.dll
 g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a  \
   /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll\

 P4.o:P4.c:(.text+0x45ac): undefined reference to `ClientApi::SetClient(char
 const*)'
 P4.o:P4.c:(.text+0x45ac): relocation truncated to fit: R_X86_64_PC32 against
 undefined symbol `ClientApi::SetClient(char const*)'
 P4.o:P4.c:(.text+0x4a9c): undefined reference to `ClientApi::SetHost(char
 const*)'

 Notice that it removes P4.dll, so it seems to know it's working with dll's,
 but then it calls g++ with a -o for libp4.a!

No it doesn't. The argument to -o is blib/arch/auto/P4/P4.dll
lib/libp4.a is the next input file. What does the following say?

nm lib/libp4.a | c++filt

 Meantime it fails with many undefined references. I think I might need to do
 perl Makefile.PL with other opts to tell it that while it's using Cygwin and
 can be very Linux-like, it needs to produce .dll's and not .a's or .o's.

It seems to be on the right track; g++ -shared -o P4.dll sounds good to me.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds

--
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: cygwin64 install g++ v 4.6.4

2014-05-29 Thread Csaba Raduly
Hi Philapol,

On Thu, May 29, 2014 at 6:19 AM, Philapol  wrote:
 Hi,
 I would like to install g++ v 4.6.4 under cygwin64 but only v 4.8.2 is
 available. What is the procedure to install this older version?

 Note: I have a large (~500K loc) C++ project that builds under Ubuntu 12.04
 LTS / g++ 4.6.4; however, it will not build under cygwin64 using g++ v 4.8.2.

What was the error message?

Have you tried building it with g++ 4.8.2 under Ubuntu 12.04?
There are PPAs for it
(http://ubuntuhandbook.org/index.php/2013/08/install-gcc-4-8-via-ppa-in-ubuntu-12-04-13-04/,
http://askubuntu.com/questions/271388/how-to-install-gcc-4-8-in-ubuntu-12-04-from-the-terminal)
or you could build a gcc 4.8.2 from source.

There's a possibility that g++4.8.2 is stricter than g++4.6.4 and your
code won't build with g++4.8.2 on any platform, in which case the
Right Thing (tm) is to correct the errors in your project.

I'm typing this on an Ubuntu LTS 12.04 so I can't check what the
previous version of GCC is on Cygwin, but it's probably some other
4.8.x so choosing previous in Cygwin's setup.exe probably won't
help.

Your options include building a GCC 4.6.4 from source or the Cygwin
Time Machine ( http://www.fruitbat.org/Cygwin/ )

HTH,
Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds

--
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: cygwin64 install g++ v 4.6.4

2014-05-29 Thread David Stacey

On 29/05/14 05:19, Philapol wrote:

I would like to install g++ v 4.6.4 under cygwin64 but only v 4.8.2 is
available. What is the procedure to install this older version?


64-bit Cygwin is relatively new, and the earliest version of gcc that 
was built for 64-bit was gcc-4.8.0 (IIRC). If you need an older version 
then you would have to build it yourself from source. But as others have 
pointed out, your time would be better spent maintaining the code so 
that it compiles with a more modern compiler.


Cheers,

Dave.


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



building cygwin packages

2014-05-29 Thread bartels
Hello,

I need to tweak and build some packages that depend on many others.

Figuring out the recursive dependencies and build order is tedious.

What is the easiest way to simply download and build *all* cygwin packages?
I have disk space and cpu time.

First, I would do 32 bit, then 64 bit.

Tia,
- Bartels

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



Mount under Task Scheduler

2014-05-29 Thread xmoon 2000
I am having trouble accessing network drive from Task Scheduler
running a bash script

I put a mount in the script and noticed that my network drives are not listed.

Is there a way to force these to be mounted when bash script starts?

Moon

--
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: Update CoreUtils

2014-05-29 Thread David Conrad
On Tue, May 13, 2014 at 11:04 AM, Christopher Faylor wrote:
 On Tue, May 13, 2014 at 09:59:03AM -0500, Steven Penny wrote:
 . . .

 Funny how you're saying We as if you are actually contributing
 anything other than criticism.


I started a thread, at one point, to ask about a newer version of git.
I offered to try to create a build, if it would help, even though
while I have over a decade of experience in the software industry I
have no experience as a Cygwin package maintainer. I also found that
Steven Penny had offered, six months or a year before my thread, to
build it. Adam Dinwoodie stepped up and offered to take over as
maintainer. He got a build out in short order, but there was a glitch
in either the cygwin dll or in openssl, I forget which, that caused
long-running git clones to fail. Once that was fixed, everything
seemed to be working except for something with git-cvs. I've never
used git-cvs, and haven't used CVS since early 2009, so I didn't know
how I could help with testing or resolving that issue. If I could
have, I would have.

I continued to use Adam's git build of 1.8.5.2 for the next couple of
months, but it slowly started to bother me more and more that I was
using a beta build. I didn't want to go back to git 1.7.9 because that
version is well over two years old now (although, admittedly, I never
had trouble with it). So I installed the native Windows git (msysgit)
1.9.2 from git-scm.org. It took a bit of configuring to get it to play
nice with Cygwin. I need git because all my company's projects are in
git (nearly; a few stragglers are still using svn). I wish there was a
Cygwin build that was, say, a year old or less.

(I still have one problem, that occasionally when it runs an external
tool, it uses its msys bash which doesn't understand SHELLOPTS=igncr,
which I need because of some stupid \r characters in the shell scripts
of npm from nodejs.)

I love Cygwin. I've been a happy user for years. Cygwin bash makes
using Windows tolerable, which makes my life better. I deeply
appreciate everything you all do, and I know that you're volunteers. I
have no claim on your time, or your effort. If I have to build a few
things myself, or use another version, I can do that. But it does look
like some people have tried to help. I'm sorry I wasn't able to be of
more help. There's no need for a reply to this. If you read this far,
then thank you for your time, and thank you for all you do.

--
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: Update CoreUtils

2014-05-29 Thread Christopher Faylor
On Thu, May 29, 2014 at 12:56:41PM -0400, David Conrad wrote:
On Tue, May 13, 2014 at 11:04 AM, Christopher Faylor wrote:
 On Tue, May 13, 2014 at 09:59:03AM -0500, Steven Penny wrote:
 . . .

 Funny how you're saying We as if you are actually contributing
 anything other than criticism.


I started a thread, at one point, to ask about a newer version of git.
I offered to try to create a build, if it would help, even though
while I have over a decade of experience in the software industry I
have no experience as a Cygwin package maintainer. I also found that
Steven Penny had offered, six months or a year before my thread, to
build it. Adam Dinwoodie stepped up and offered to take over as
maintainer. He got a build out in short order, but there was a glitch
in either the cygwin dll or in openssl, I forget which, that caused
long-running git clones to fail. Once that was fixed, everything
seemed to be working except for something with git-cvs. I've never
used git-cvs, and haven't used CVS since early 2009, so I didn't know
how I could help with testing or resolving that issue. If I could
have, I would have.

I continued to use Adam's git build of 1.8.5.2 for the next couple of
months, but it slowly started to bother me more and more that I was
using a beta build. I didn't want to go back to git 1.7.9 because that
version is well over two years old now (although, admittedly, I never
had trouble with it). So I installed the native Windows git (msysgit)
1.9.2 from git-scm.org. It took a bit of configuring to get it to play
nice with Cygwin. I need git because all my company's projects are in
git (nearly; a few stragglers are still using svn). I wish there was a
Cygwin build that was, say, a year old or less.

(I still have one problem, that occasionally when it runs an external
tool, it uses its msys bash which doesn't understand SHELLOPTS=igncr,
which I need because of some stupid \r characters in the shell scripts
of npm from nodejs.)

I love Cygwin. I've been a happy user for years. Cygwin bash makes
using Windows tolerable, which makes my life better. I deeply
appreciate everything you all do, and I know that you're volunteers. I
have no claim on your time, or your effort. If I have to build a few
things myself, or use another version, I can do that. But it does look
like some people have tried to help. I'm sorry I wasn't able to be of
more help. There's no need for a reply to this. If you read this far,
then thank you for your time, and thank you for all you do.

The intent of this message isn't clear to me.  You've just filled us all
in on your experience trying to use git and noted that we need a git
maintainer.  I guess people who aren't aware of that are now aware.  So
the bottom line is that git's status is: missing a maintainer, hoping
for someone to pick it up.

Hopefully the subtext isn't that this is stalled because someone like
Corinna or I didn't jump in to try to fix problems with git...

cgf

--
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: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs

2014-05-29 Thread Reini Urban
On May 2, 2014, at 3:32 AM, Achim Gratz wrote:

 Reini Urban writes:
 perl, perl_vendor, perl_manpages, perl_debugbuild
 
 The debug package is actually named perl_debuginfo at the moment, but
 perhaps it should be renamed perl-debuginfo to conform to all other
 packages?

probably.

I also found out that several vendor packages are now separated on x86_64, 
so I’ll have to split them also for 32bit. Lot more work todo for me, but 
apparently
some guys just went ahead.

 @INC looks strange: why do you keep vendor_perl for 5.10, but not for
 5.14?  Do we really want to fall back to site_perl 5.10 and 5.8 these
 days?

oops, vendor_perl/5.14 is missing.

yes, falling back to good old arch-unspecific code is no problem and 
saves installation time and space.
and we did support those versions.

still working on unexpected socketpair problems with 64bit.


--
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: Building cpan module that links with proprietary libs

2014-05-29 Thread Andrew DeFaria

On 5/29/2014 1:29 AM, Csaba Raduly wrote:

Hi Andrew,

On Thu, May 29, 2014 at 4:12 AM, Andrew DeFaria  wrote:

I'm attempting to build a cpan module (well actually it's not a cpan module
but rather a module that uses MakeMaker and has the familiar perl
Makefile.PL, make, make test, make install installation procedure.
Additionally I need to link it to a set of proprietary libs that I am given
only the .lib files for. If you must know this is for Perforce's P4Perl
which I'd like to get working with Cygwin's Perl natively.

I download the P4API bundle (the package that has include files and the .lib
files pre-compiled).


The C++ P4 API is platform-specific; which platform did you choose?
If it really contains .lib files (not .a), those are not recognized by
Cygwin's gcc.


I had two archives two choose from. One was for Windows and contained 
the .lib files. The other was for Linux and contains .a files. I first 
tried the Linux one but that failed with:


g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a  \
  /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll 
-L/cygdrive/a/p4perlBuild/p4api/lib -lclient -lrpc -lsupp -lp4sslstub 
   \


collect2: error: ld terminated with signal 11 [Segmentation fault], core 
dumped

Makefile:531: recipe for target 'blib/arch/auto/P4/P4.dll' failed
make: *** [blib/arch/auto/P4/P4.dll] Error 1
Adefaria-lt:

I can give you more output if you need it.

Then I switched to the Windows archive that contained the .lib files.

I think the issue is that their Windows P4Perl build system uses Visual 
Studio to build and on Linux it uses g++. Their installation package is 
only for ActiveState. Supposedly at 5.18 ActiveState is changing to a 
g++ based backend using MingW I think so they'll eventually have to 
figure this out. Meantime I'm just trying to get it working under 
Cygwin's Perl...



Next I need to do:

$ perl Makefile.PL --api-dir /.../path/to/unzipped/p4api

This works fine and I procedure with the make. This fails with things like:

make[1]: Leaving directory '/cygdrive/a/perl/P4Perl.Cygwin/lib'
g++ -c  -I/cygdrive/a/perl/p4api.windows/include/p4 -Ilib -x c++
-DUSEIMPORTLIB -O3   -DVERSION=\2014.1\ -DXS_VERSION=\2014.1\
-I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE
-DID_OS=\CYGWIN17THREAD\ -DID_REL=\2014.1\ -DID_PATCH=\842847\
-DID_Y=\2014\ -DID_M=\05\ -DID_D=\06\ -DOS_CYGWIN -DOS_CYGWIN17
-DOS_CYGWIN17THREAD -DOS_CYGWINTHREAD -DP4API_VERSION=515585
-DID_API=\2014.1/821990\ P4.c
Running Mkbootstrap for P4 ()
chmod 644 P4.bs
rm -f blib/arch/auto/P4/P4.dll
g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a  \
   /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll\

P4.o:P4.c:(.text+0x45ac): undefined reference to `ClientApi::SetClient(char
const*)'
P4.o:P4.c:(.text+0x45ac): relocation truncated to fit: R_X86_64_PC32 against
undefined symbol `ClientApi::SetClient(char const*)'
P4.o:P4.c:(.text+0x4a9c): undefined reference to `ClientApi::SetHost(char
const*)'

Notice that it removes P4.dll, so it seems to know it's working with dll's,
but then it calls g++ with a -o for libp4.a!


No it doesn't. The argument to -o is blib/arch/auto/P4/P4.dll
lib/libp4.a is the next input file.


Good catch! I missed that.

 What does the following say?


nm lib/libp4.a | c++filt


Attached.


Meantime it fails with many undefined references. I think I might need to do
perl Makefile.PL with other opts to tell it that while it's using Cygwin and
can be very Linux-like, it needs to produce .dll's and not .a's or .o's.


It seems to be on the right track; g++ -shared -o P4.dll sounds good to me.


Thanks for your help.
--
Andrew DeFaria
http://defaria.com

p4actionmerge.o:
 b .bss
 d .data
 p .pdata
 r .rdata
 r .rdata$.refptr._ZN6StrBuf10nullStrBufE
 r .rdata$zzz
 R .refptr._ZN6StrBuf10nullStrBufE
 t .text
 r .xdata
 U Perl_newSVpv
 U _Unwind_Resume
0350 T P4ActionMergeData::GetMergeHint()
0080 T P4ActionMergeData::GetMergeInfo()
0140 T P4ActionMergeData::GetYourAction()
0090 T P4ActionMergeData::GetMergeAction()
01f0 T P4ActionMergeData::GetTheirAction()
02a0 T P4ActionMergeData::GetType()
0380 T P4ActionMergeData::GetString()
 T P4ActionMergeData::P4ActionMergeData(ClientUser*, 
ClientResolveA*, StrPtr, sv*)
 T P4ActionMergeData::P4ActionMergeData(ClientUser*, 
ClientResolveA*, StrPtr, sv*)
 U StrBuf::nullStrBuf
 U StrBuf::Append(StrPtr const*)
 U StrBuf::Append(char const*)
 U Error::Fmt(StrBuf, int) const
 U operator delete[](void*)
 U __gxx_personality_seh0
 U __imp_PL_thr_key
 U __real__ZdaPv
 

Re: [ANNOUNCEMENT] Updated: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs

2014-05-29 Thread Achim Gratz
Reini Urban writes:
 I also found out that several vendor packages are now separated on x86_64, 
 so I’ll have to split them also for 32bit. Lot more work todo for me, but 
 apparently
 some guys just went ahead.

My offer for help still stands.

 @INC looks strange: why do you keep vendor_perl for 5.10, but not for
 5.14?  Do we really want to fall back to site_perl 5.10 and 5.8 these
 days?

 oops, vendor_perl/5.14 is missing.

BTW, would it be possible to enable the site-config option in the next
Perl build to allow massaging @INC on a per-installation basis if
necessary?


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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



make install problem for emms (Permission denied)

2014-05-29 Thread Filipp Gunbin
While trying a fix for this emms build bug:
http://lists.gnu.org/archive/html/emms-help/2014-05/msg0.html I ran
into a strange problem:

install -m 644 lisp/emms-info-mp3info.el lisp/tq.el lisp/emms-url.el 
lisp/emms-player-mpg321-remote.el lisp/emms-mode-line-icon.el 
lisp/emms-info-metaflac.el lisp/emms-metaplaylist-mode.el lisp/emms-score.el 
lisp/emms-volume.el lisp/emms-info-ogginfo.el lisp/emms-last-played.el 
lisp/emms-playing-time.el lisp/emms-player-simple.el 
lisp/emms-librefm-scrobbler.el lisp/emms-stream-info.el lisp/emms-cue.el 
lisp/emms-player-xine.el lisp/emms-tag-editor.el lisp/emms-librefm-stream.el 
lisp/emms-playlist-sort.el lisp/emms-player-mpd.el lisp/emms.el 
lisp/emms-info-libtag.el lisp/later-do.el lisp/emms-setup.el 
lisp/emms-mode-line.el lisp/emms-player-mplayer.el lisp/emms-history.el 
lisp/emms-cache.el lisp/emms-maint.el lisp/emms-compat.el 
lisp/emms-playlist-limit.el lisp/emms-auto.el lisp/emms-volume-amixer.el 
lisp/emms-i18n.el lisp/emms-playlist-mode.el lisp/jack.el 
lisp/emms-player-vlc.el lisp/emms-lyrics.el lisp/emms-streams.el 
lisp/emms-mark.el lisp/emms-info.el lisp/emms-source-playlist.el 
lisp/emms-source-file.el lisp/emms-browser.el lisp/emms-bookmarks.el 
/usr/local/share/emacs/site-lisp/emms

make: execvp: install: Permission denied

I think this is Cygwin-specific.  I see some similar problems in cygwin
list archives, but they occured a long ago and there are not much
complaints.

Yes, all permissions seem to be ok.

However, some days ago it worked, probably I updated Cygwin since then,
I don't remember exactly.  If yes, then it was an update from
November-2013 version to the current.  I tried a snapshot from that time
and a latest snapshot, both with no luck.

Any thoughts?

Thanks.

-- 
Filipp Gunbin

--
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: make install problem for emms (Permission denied)

2014-05-29 Thread Christopher Faylor
On Fri, May 30, 2014 at 01:50:49AM +0400, Filipp Gunbin wrote:
Also, it's strange that the install... command above works when run
directly in shell, but fails when run from make.

Which implies that you probably are not running /usr/bin/install.

cgf

--
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: make install problem for emms (Permission denied)

2014-05-29 Thread Filipp Gunbin
On 30/05/2014 01:53 +0400, Christopher Faylor wrote:

 On Fri, May 30, 2014 at 01:50:49AM +0400, Filipp Gunbin wrote:
Also, it's strange that the install... command above works when run
directly in shell, but fails when run from make.

 Which implies that you probably are not running /usr/bin/install.

 cgf

Thanks!  I didn't notice.  I'll post to the emms-help about this problem.

-- 
Filipp Gunbin

--
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: Update CoreUtils

2014-05-29 Thread Steven Penny
On Thu, May 29, 2014 at 12:11 PM, Christopher Faylor wrote:
 So the bottom line is that git's status is: missing a maintainer, hoping
 for someone to pick it up.

You have short term memory?

http://cygwin.com/ml/cygwin/2014-05/msg00255.html
http://cygwin.com/ml/cygwin/2014-05/msg00279.html

--
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: binutils-2.24.51-3 (x86/x86_64)

2014-05-29 Thread Ken Brown

On 5/28/2014 11:13 PM, Christopher Faylor wrote:

I've made a new version of binutils available for installation.  This is
a refresh against the official git repository.  The binutils package
contains the GNU assembler, linker and binary utilities.  It is
available in the Devel category under Cygwin's setup.


Thanks.  Unfortunately, the problem I reported in 
https://cygwin.com/ml/cygwin/2014-04/msg00199.html doesn't seem to have 
been fixed.  I thought it was supposed to be fixed as part of binutils 
bug 16807.  I've sent an additional comment to that bug report:


  https://sourceware.org/bugzilla/show_bug.cgi?id=16807#c12

Ken

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



Buying

2014-05-29 Thread Ferotehna D . O . O

Dear,

We are very interested in Buying your Products.
Please kindly send the us the following.
1. Delivery time of the Product
2. Product warranty
3. Minimum Order Quantity
4. Payment TERM

Thanks  Best Regards,
Aleksandar Barak

Ferotehna D.O.O
Kukuljanovo.312
51227 Kukuljanovo-Rijeka-Croatia
Tel:+385 (0)51 503 107
Mob:+385 (0)91 150 3459
Fax:+385 (0)51 503 105
Email: info.ferote...@gmail.com
Skype: aleksandar.feroteh


--
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: Update CoreUtils

2014-05-29 Thread Chris J. Breisch

Steven Penny wrote:

On Thu, May 29, 2014 at 12:11 PM, Christopher Faylor wrote:

So the bottom line is that git's status is: missing a maintainer, hoping
for someone to pick it up.


You have short term memory?

http://cygwin.com/ml/cygwin/2014-05/msg00255.html
http://cygwin.com/ml/cygwin/2014-05/msg00279.html



Do you?

https://cygwin.com/ml/cygwin/2014-05/msg00284.html

From the same thread. Amazing that you missed that.

--
Chris J. Breisch

--
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: Update CoreUtils

2014-05-29 Thread Steven Penny
On Thu, May 29, 2014 at 7:04 PM, Chris J. Breisch wrote:
 Do you?

 https://cygwin.com/ml/cygwin/2014-05/msg00284.html

 From the same thread. Amazing that you missed that.

You are out of your element, mate

https://cygwin.com/ml/cygwin/2014-05/msg00298.html

--
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: Mount under Task Scheduler

2014-05-29 Thread Larry Hall (Cygwin)

On 05/29/2014 11:40 AM, xmoon 2000 wrote:

I am having trouble accessing network drive from Task Scheduler
running a bash script

I put a mount in the script and noticed that my network drives are not listed.

Is there a way to force these to be mounted when bash script starts?


https://cygwin.com/faq.html#faq.using.shares

Similar problem, different service, still the same solutions.


--
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: Building cpan module that links with proprietary libs

2014-05-29 Thread Larry Hall (Cygwin)

On 05/29/2014 01:48 PM, Andrew DeFaria wrote:

On 5/29/2014 1:29 AM, Csaba Raduly wrote:

Hi Andrew,

On Thu, May 29, 2014 at 4:12 AM, Andrew DeFaria  wrote:

I'm attempting to build a cpan module (well actually it's not a cpan module
but rather a module that uses MakeMaker and has the familiar perl
Makefile.PL, make, make test, make install installation procedure.
Additionally I need to link it to a set of proprietary libs that I am given
only the .lib files for. If you must know this is for Perforce's P4Perl
which I'd like to get working with Cygwin's Perl natively.

I download the P4API bundle (the package that has include files and the .lib
files pre-compiled).


The C++ P4 API is platform-specific; which platform did you choose?
If it really contains .lib files (not .a), those are not recognized by
Cygwin's gcc.


I had two archives two choose from. One was for Windows and contained the
.lib files. The other was for Linux and contains .a files. I first tried the
Linux one but that failed with:

g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a  \
   /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll
-L/cygdrive/a/p4perlBuild/p4api/lib -lclient -lrpc -lsupp -lp4sslstub\

collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
Makefile:531: recipe for target 'blib/arch/auto/P4/P4.dll' failed
make: *** [blib/arch/auto/P4/P4.dll] Error 1
Adefaria-lt:

I can give you more output if you need it.


No need.  Forgive me for saying this but I find it hard to believe that
after all this time on the list Andrew that you don't know that trying to
use Linux-compiled libraries on Cygwin isn't going to work.  But I guess
my surprise is not that important here. ;-)


Then I switched to the Windows archive that contained the .lib files.


Sensible but...


I think the issue is that their Windows P4Perl build system uses Visual
Studio to build and on Linux it uses g++. Their installation package is only
for ActiveState. Supposedly at 5.18 ActiveState is changing to a g++ based
backend using MingW I think so they'll eventually have to figure this out.
Meantime I'm just trying to get it working under Cygwin's Perl...


Next I need to do:

$ perl Makefile.PL --api-dir /.../path/to/unzipped/p4api

This works fine and I procedure with the make. This fails with things like:

make[1]: Leaving directory '/cygdrive/a/perl/P4Perl.Cygwin/lib'
g++ -c  -I/cygdrive/a/perl/p4api.windows/include/p4 -Ilib -x c++
-DUSEIMPORTLIB -O3   -DVERSION=\2014.1\ -DXS_VERSION=\2014.1\
-I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE
-DID_OS=\CYGWIN17THREAD\ -DID_REL=\2014.1\ -DID_PATCH=\842847\
-DID_Y=\2014\ -DID_M=\05\ -DID_D=\06\ -DOS_CYGWIN -DOS_CYGWIN17
-DOS_CYGWIN17THREAD -DOS_CYGWINTHREAD -DP4API_VERSION=515585
-DID_API=\2014.1/821990\ P4.c
Running Mkbootstrap for P4 ()
chmod 644 P4.bs
rm -f blib/arch/auto/P4/P4.dll
g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a  \
   /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll\

P4.o:P4.c:(.text+0x45ac): undefined reference to `ClientApi::SetClient(char
const*)'
P4.o:P4.c:(.text+0x45ac): relocation truncated to fit: R_X86_64_PC32 against
undefined symbol `ClientApi::SetClient(char const*)'
P4.o:P4.c:(.text+0x4a9c): undefined reference to `ClientApi::SetHost(char
const*)'

Notice that it removes P4.dll, so it seems to know it's working with dll's,
but then it calls g++ with a -o for libp4.a!


No it doesn't. The argument to -o is blib/arch/auto/P4/P4.dll
lib/libp4.a is the next input file.


Good catch! I missed that.

  What does the following say?


nm lib/libp4.a | c++filt


Attached.


Meantime it fails with many undefined references. I think I might need to do
perl Makefile.PL with other opts to tell it that while it's using Cygwin and
can be very Linux-like, it needs to produce .dll's and not .a's or .o's.


It seems to be on the right track; g++ -shared -o P4.dll sounds good to me.


You say that the libs were built by Visual Studio and the remainder of your
comments make it clear that the libraries are C++ and not C code.  As a
result, you will never get code compiled with g++ to link with these
libraries.  There is no common ABI among C++ compilers.  Thus, the libraries
and headers of one can't be used as input to the compiler of another, even
on the same platform.  This only works for C code.  So you have to either
build the proprietary libs with Cygwin's C++ compiler or write your own
shim library that wraps the necessary calls and objects in a C API,
compile that with VS, and link your program against the APIs in your
library.


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

Re: Building cpan module that links with proprietary libs

2014-05-29 Thread Andrew DeFaria

On 5/29/2014 6:42 PM, Larry Hall (Cygwin) wrote:


I had two archives two choose from. One was for Windows and contained the
.lib files. The other was for Linux and contains .a files. I first
tried the
Linux one but that failed with:

g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a  \
   /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll
-L/cygdrive/a/p4perlBuild/p4api/lib -lclient -lrpc -lsupp
-lp4sslstub\

collect2: error: ld terminated with signal 11 [Segmentation fault],
core dumped
Makefile:531: recipe for target 'blib/arch/auto/P4/P4.dll' failed
make: *** [blib/arch/auto/P4/P4.dll] Error 1
Adefaria-lt:

I can give you more output if you need it.


No need.  Forgive me for saying this but I find it hard to believe that
after all this time on the list Andrew that you don't know that trying to
use Linux-compiled libraries on Cygwin isn't going to work.  But I guess
my surprise is not that important here. ;-)


When I first when to get this to work I choose the Linux style of the 
package for p4api. I figured the Windows style was for ActiveState only 
and that'd probably not work. Hell ActiveState doesn't even use cpan, 
they use ppm. I didn't look inside for anything like .o, .a or .dll or 
.lib. I figured that it would have been source code and it would have 
been compiled as part of the make process. It wasn't until it failed 
that I saw the reference to .a's, etc. and looked into the p4api 
directory structure to see .lib's in the Windows copy and .a's in the 
Linux copy. Sure at *that* point I knew the Linux style will never work 
in this situation. So I tried to link with the Windows style .lib copy.



It seems to be on the right track; g++ -shared -o P4.dll sounds
good to me.


You say that the libs were built by Visual Studio and the remainder of your
comments make it clear that the libraries are C++ and not C code.


I don't believe I ever said it was just C code. If I did then I'm sorry.


As a
result, you will never get code compiled with g++ to link with these
libraries.  There is no common ABI among C++ compilers.  Thus, the
libraries
and headers of one can't be used as input to the compiler of another, even
on the same platform.  This only works for C code.  So you have to either
build the proprietary libs with Cygwin's C++ compiler or write your own
shim library that wraps the necessary calls and objects in a C API,
compile that with VS, and link your program against the APIs in your
library.


Being as this code is proprietary I doubt that Perforce will release it 
to me to compile but I will point them at this thread...'


Thanks.
--
Andrew DeFaria
http://defaria.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