updating Perl problem

2020-03-20 Thread Marco Atzeri via Cygwin 

Hi,
trying to update some of Yaakov's perl packages I hit this

>>> Compiling perl-Pango-1.227-3.x86_64
Pre-requisites not found:
Can't locate ExtUtils/Depends.pm in @INC (you may need to install the 
ExtUtils::Depends module) (@INC contains: 
/usr/local/lib/perl5/site_perl/5.30/x86_64-cygwin-threads 
/usr/local/share/perl5/site_perl/5.30 
/usr/lib/perl5/vendor_perl/5.30/x86_64-cygwin-threads 
/usr/share/perl5/vendor_perl/5.30 
/usr/lib/perl5/5.30/x86_64-cygwin-threads /usr/share/perl5/5.30) at 
(eval 21) line 1.

BEGIN failed--compilation aborted at (eval 21) line 1.

Please install them manually.
make: *** No rule to make target 'all'.  Stop.
*** ERROR: make failed

$ cygcheck -l perl-ExtUtils-Depends
/usr/share/doc/perl-ExtUtils-Depends/CHANGES
/usr/share/doc/perl-ExtUtils-Depends/README
/usr/share/man/man3/ExtUtils.Depends.3pm.gz
/usr/share/perl5/vendor_perl/5.30/ExtUtils/Depends.pm

Any I idea why it is failing?

Perl is not a language I am familiar with, of course.

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

Re: Why is taskset still not in util-linux?

2020-03-20 Thread Eliot Moss 

On 3/20/2020 1:54 AM, Mark Geisert wrote:

Mark Geisert wrote:

Eliot Moss wrote:


Rats.  Sorry you've hit some snags.  Are you compiling directly with 'make' or the preferred 
'cygport util-linux.cygport build'?  With the latter I didn't need to make any changes to the 
source tree; all mods were accomplished with the new patch file and changes to util-linux.cygport 
itself.


I've reproduced your snags.  It/they are due to my having forgotten another tiny update that should 
have been part of the 2.33.1-cygwin-cpuset.patch file.  If you 'echo "#define SYS_sched_getaffinity 
42" > /usr/local/include/sys/syscall.h' and then back out your other fix attempts, the build using 
cygport should work.


What an amusing hack!  I especially like the sensibility of 42!  :-)

I will try this.  When I built it last night, I got a successful compile, but 
it didn't do anything.
For example, taskset 1 ls did not output _anything_ -- no error message and no 
ls output :-( ...

It will be the weekend here in Australia (I'm visiting, and wondering about 
exactly how and when I
will get home) so maybe I'll play with it some more on Saturday ...

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

Re: Why is taskset still not in util-linux?

2020-03-20 Thread Yaakov Selkowitz 
On Thu, 2020-03-19 at 22:54 -0700, Mark Geisert wrote:
> Mark Geisert wrote:
> > Eliot Moss wrote:
> > > On 3/16/2020 7:34 PM, Mark Geisert wrote:
> > >  > Mark Geisert wrote:
> > >  >> Eliot Moss wrote:
> > >  >>>
> > >  >>> Dear cygwin-ers --
> > >  >>>
> > >  >>> Something I had asked about a while ago was the absence os taskset 
> > > in 
> > > cygwin's
> > >  >>> util-linux.  At the time, it was pointed out that the necessary 
> > > get/set
> > >  >>> affinity library/system calls were not yet supported.  These were 
> > > added a
> > >  >>> while ago, so it would seem that taskset ought to work.  In fact, I 
> > > think
> > >  >>> someone got it going on their own.  Can we add it to util-linux now,
> > >  >>> officially?  I think this was intended but perhaps was overlooked or
> > >  >>> something.
> > >  >>
> > >  >> Report noted; thanks.  A solution is being worked.
> > >  >
> > >  > There's been no forward progress on this.  If you're comfortable 
> > > getting 
> > > the util-linux source
> > >  > package through Cygwin setup*.exe, you can follow the steps shown in
> > >  > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to 
> > > build 
> > > (with cygport) a local copy
> > >  > of util-linux that includes a taskset.exe you can move into 
> > > /usr/local/bin, 
> > > for example.
> > >  >
> > >  > You might try that route if you're up for it.  Feel free to ask 
> > > questions 
> > > here if you hit a snag.
> > >  > HTH,
> > > 
> > > Thank you, Mark.  I decided to give it a try and got some distance, but 
> > > hit a 
> > > snag.
> > > 
> > > First, I had to change configure.ac to add control to disable ionice 
> > > (Cygwin
> > > does not support a required syscall) while still trying to build taskset.
> > > Previously taskset and ionice (and one other program) were controlled by 
> > > the
> > > single --enable-schedutils.
> > > 
> > > Now, including sched.h does not provide the prototypes for 
> > > sched_getaffinity,
> > > etc.  I found a previous post that suggests we need to do -D_GNU_SOURCE 
> > > for it
> > > to work.  I am not sure of the best place to stick that, but I will see 
> > > about
> > > maybe a one line patch to taskset.c or something.
> > 
> > Rats.  Sorry you've hit some snags.  Are you compiling directly with 'make' 
> > or 
> > the preferred 'cygport util-linux.cygport build'?  With the latter I didn't 
> > need 
> > to make any changes to the source tree; all mods were accomplished with the 
> > new 
> > patch file and changes to util-linux.cygport itself.
> 
> I've reproduced your snags.  It/they are due to my having forgotten another 
> tiny 
> update that should have been part of the 2.33.1-cygwin-cpuset.patch file.  If 
> you 'echo "#define SYS_sched_getaffinity 42" > 
> /usr/local/include/sys/syscall.h' 
> and then back out your other fix attempts, the build using cygport should 
> work.

Cygwin doesn't support syscalls.  I'd be very wary of any code which is
conditional on any #ifdef SYS_*.

--
Yaakov


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

Re: updating Perl problem

2020-03-20 Thread ASSI 
Marco Atzeri via Cygwin writes:
 Compiling perl-Pango-1.227-3.x86_64
> Pre-requisites not found:
> Can't locate ExtUtils/Depends.pm in @INC (you may need to install the
> ExtUtils::Depends module)

Does that also fail with

perl -MExtUtils::Depends < /dev/null && echo OK || echo Fail

and if yes, is the file readable for the euid you are compiling under?


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

using cygwin with an encrypted external drive

2020-03-20 Thread Keeler, Lisa 
Hello,

I love Cygwin, and have used it for many years so that I can use emacs, grep, 
and all other useful linux tools against my Windows file system.

I have the latest version of Cygwin:  2.903  64bit

Previously, I had an external passport drive which was not encrypted, and I was 
able to use it in Cygwin just fine, no problem, using /cygdrive/d/...

Now, my external passport drive has been encrypted by McAfee encryption, per 
policy for my company.

Now, I can see the files OK on the Windows File Explorer, but when I look at 
the /cygdrive/d in Cygwin, I see nothing useful at all.

Below is a comparison between what I see in Cygwin -vs- what I see from a 
Windows command prompt:

LKEELER@AM-lkeeler-W3 /cygdrive/d
$ ls -la
total 6209
drwxr-xr-x 1 LKEELER ADPROD+Group(513)   0 Mar 19 08:06  .
dr-xr-xr-x 1 LKEELER ADPROD+Group(513)   0 Mar 20 09:49  ..
-r--r--r-- 1 LKEELER ADPROD+Group(513) 134 Mar 18 18:00  autorun.inf
drwxr-xr-x 1 LKEELER ADPROD+Group(513)   0 Mar 18 18:00 'McAfee EERM'
drwxr-xr-x 1 LKEELER ADPROD+Group(513)   0 Mar 18 18:00 'McAfee Removable 
Media Protection.app'
-r-xr-xr-x 1 LKEELER ADPROD+Group(513)  669840 Jul 10  2019  mfecc32.dll
-r-xr-xr-x 1 LKEELER ADPROD+Group(513) 5418752 Jul 10  2019  MfeEERM.exe
drwxr-xr-x 1 LKEELER ADPROD+Group(513)   0 Mar 19 08:07 'System Volume 
Information'
^[]0;/cygdrive/d^G
LKEELER@AM-lkeeler-W3 /cygdrive/d
$

D:\>dir
Volume in drive D is MY PASSPORT
Volume Serial Number is 07D6-45BC

Directory of D:\

03/18/2020  07:44 PM  ADDM
03/18/2020  07:45 PM  Dropbox
03/18/2020  07:47 PM  Customer
01/13/2016  02:49 PM30,258 KTTraining.docx
02/26/2015  02:48 PM   144,384 Sftp_User.doc
11/09/2018  02:11 PM70,997 Winsock Reset (Avecto).docx
03/18/2020  04:58 PM  CMDB
03/18/2020  04:58 PM  HELIX_DISCOVERY_ACCELERATORS
03/18/2020  04:59 PM  pictures
02/24/2017  11:43 AM 1,277,989 jackie.zip
03/05/2020  09:59 AM  CUSTOMIZATION101
03/05/2020  12:40 PM  DiscoveryCustomization101
03/18/2020  05:22 PM  Customer3
   4 File(s)  1,523,628 bytes
   9 Dir(s)  1,909,672,902,656 bytes free

Thanks,
Lisa Keeler
BMC Software
lisa_kee...@bmc.com



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

Re: crontab message "must be privileged to use -u"

2020-03-20 Thread Stephen Carrier 
On Wed, Mar 18, 2020 at 10:54:51PM +0300, Andrey Repin wrote:
> Greetings, All!
> 
> I'm trying to use Cygwin's cron, but have a small issue:
> 
> # crontab -u 18 -l
> must be privileged to use -u
> 
> Is there a way around the problem?
> I'm in an elevated shell, but it seems crontab is doing a dumb POSIX check for
> EUID=0.

For me the way around this has been to view (or edit) directly the file
in /var/cron/tabs.  If you edit the file, cron needs to be restarted.

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

[ANNOUNCEMENT] Updated: Perl distributions

2020-03-20 Thread Achim Gratz 



The following Perl distributions have been updated to their latest
version on CPAN, respectively:

x86/x86_64
--

perl-Alien-Libxml2-0.15-1
perl-Crypt-OpenSSL-EC-1.32-1
perl-XML-LibXML-2.0204-1


noarch
--

perl-Alien-Build-2.17-1
perl-Business-ISSN-1.004-1
perl-Mojolicious-8.34-1
perl-Net-DNS-1.23-1


-- 
  *** 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:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

2020-03-20 Thread Hans-Bernhard Bröker 

Am 20.03.2020 um 00:18 schrieb Brian Inglis:

On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote:



It seems something is adding 5M or more to the normal
size of the programs


See attached for summary details by arch, but main points for both are, on 
x86_64:

[...]

Could this be due to the ginormous number of targets configured into the 
build?


Asking the tools themselves about the list of targets they support, 
compared to a run-off-the-mill default native build from current git 
sources, yields:



hbbro@NB5 ~/src/gnu/binutils/bld/gcc/binutils
$ objdump -i | wc
   8172   30919  441168

hbbro@NB5 ~/src/gnu/binutils/bld/gcc/binutils
$ ./objdump -i | wc
117 3252831


That size difference evidently due to the 260+ supported output target 
types in /usr/bin/objdump.exe, compared to 22 in my own build.


To put it another way the individual object files in libbfd.a are of 
quite similar size; there just a whole lot more of them, and that 
explains the difference.

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

Re: Why is taskset still not in util-linux?

2020-03-20 Thread Andrey Repin 
Greetings, Eliot Moss!

>> I've reproduced your snags.  It/they are due to my having forgotten another
>> tiny update that should have been part of the 2.33.1-cygwin-cpuset.patch
>> file.  If you
>> 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h'
>> and then back out your other fix attempts, the build using cygport should 
>> work.

> What an amusing hack!  I especially like the sensibility of 42!  :-)

Because that's THE ANSWER!

> I will try this.  When I built it last night, I got a successful compile,
> but it didn't do anything.  For example, taskset 1 ls did not output
> _anything_ -- no error message and no ls output :-( ...

> It will be the weekend here in Australia (I'm visiting, and wondering about
> exactly how and when I will get home) so maybe I'll play with it some more
> on Saturday ...


-- 
With best regards,
Andrey Repin
Saturday, March 21, 2020 0:41:58

Sorry for my terrible english...
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Why is taskset still not in util-linux?

2020-03-20 Thread Eliot Moss 

On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote:

> Cygwin doesn't support syscalls.  I'd be very wary of any code which is
> conditional on any #ifdef SYS_*.

Of course.  AFAICT taskset does not need the syscall, it just needs the
library call to work.  Asking about the syscall is, I suppose, a kind of Linux
shorthand to see if something is supported on the particular platform.  Mark's
suggestion of providing a fake definition of that syscall definition is a
workaround that may disturb the util-linux sources the least.

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

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

2020-03-20 Thread Marco Atzeri via Cygwin 

Am 20.03.2020 um 20:24 schrieb Hans-Bernhard Bröker:

Am 20.03.2020 um 00:18 schrieb Brian Inglis:

On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote:



It seems something is adding 5M or more to the normal
size of the programs


See attached for summary details by arch, but main points for both 
are, on x86_64:

[...]

Could this be due to the ginormous number of targets configured into the 
build?


may be, as it also take ages to full compile with the
current configuration:

#   --enable-shared
CYGCONF_ARGS="
--enable-install-libiberty
--disable-gdb
--disable-libdecnumber
--disable-readline
--disable-sim
--enable-64-bit-bfd
--enable-targets=all
"

I am testing a build dropping the "enable-targets=all"
and also forcing the "enable-shared"

 --enable-shared \
lt_cv_deplibs_check_method=pass_all


Hoping it will note ages again

Marco



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

Re: Why is taskset still not in util-linux?

2020-03-20 Thread Eliot Moss 

On 3/20/2020 1:54 AM, Mark Geisert wrote:

> I've reproduced your snags.  It/they are due to my having forgotten another 
tiny update that should
> have been part of the 2.33.1-cygwin-cpuset.patch file.  If you 'echo "#define 
SYS_sched_getaffinity
> 42" > /usr/local/include/sys/syscall.h' and then back out your other fix 
attempts, the build using
> cygport should work.

Dear Mark:

Once I did that properly, it built without commenting out that test.  Yay!

We still need to suppress building ionice, which requires patching
configure.ac to provide a separate flag for that.  And we still need to
#define _GNU_SOURCE before the #include  to make the
sched_get/setaffinity calls visible.  I intend to patch that into taskset.c
unless you have a better way of doing it.

When I do all this and use 'cygport compile', I get a taskset that appears to
work ...  as long as I run it in the place where it was built.  When I install
it, it fails, pretty silently.  I have strace outputs from the two cases, but
don't know enough about internals to interpret them.  It seems that the
failure is errno 2, ENOENT.

The permissions on the file in the build area and the one in /usr/bin are the
same (according to both getfacl and icacls) and they are on the same drive.
'cmp' indicates that the file contents are the same.  It's pretty confusing.
I've never seen anything like it.  It doesn't matter if I give the full path
'/usr/bin/taskset' or the shorter 'taskset'.  The containing directories have
slightly different permissions, but lots of other files in /usr/bin load and
run.

By running the version in the build directory on a somewhat long-running ls
command, and using taskset -p on that running ls from another window, I
verified that the affinity mask is indeed getting set.  (It was less obvious
to me how to tell which cpu it was actually running on.)

Your thoughts about not being able to run the installed version?

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

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

2020-03-20 Thread Marco Atzeri via Cygwin 

Am 21.03.2020 um 05:55 schrieb Marco Atzeri:

Am 20.03.2020 um 20:24 schrieb Hans-Bernhard Bröker:

Am 20.03.2020 um 00:18 schrieb Brian Inglis:

On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote:



It seems something is adding 5M or more to the normal
size of the programs


See attached for summary details by arch, but main points for both 
are, on x86_64:

[...]

Could this be due to the ginormous number of targets configured into 
the build?


may be, as it also take ages to full compile with the
current configuration:

#   --enable-shared
CYGCONF_ARGS="
     --enable-install-libiberty
     --disable-gdb
     --disable-libdecnumber
     --disable-readline
     --disable-sim
     --enable-64-bit-bfd
     --enable-targets=all
"

I am testing a build dropping the "enable-targets=all"
and also forcing the "enable-shared"

  --enable-shared \
     lt_cv_deplibs_check_method=pass_all


Hoping it will note ages again


"NOT take"




Marco



dropping the target seems to work very well

current version
$ du -sb /usr/bin/gprof.exe
5424147 /usr/bin/gprof.exe

under build
$ du -sb gprof/gprof.exe
19968   gprof/gprof.exe


Jon,
any clue why we are using a "enable-targets=all" options ?
Any cross compiler should use its own binutils not the cygwin one, correct ?

Marco




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