Interesting...

In 00-compile.t in PerlIO::Layers the test attempts to run a perl -e
'require PerlIO/Layers.pm' as a child process. It then does a waitpid() to
get the exit status of that perl script process. It then tests $? against
0, and if TRUE, reports test-ok.  Wrong! Man, is that wrong. The exit value
of a Unix process reaped by waitpid() must be shifted right some number of
bits to isolate the value returned by the child process. In Perl, $? must
be shifted right some number of bits to get the exit status. From the *.t
file:

waitpid($pid, 0);
is($?, 0, "$lib loaded ok");

The perldoc page for wait3() uses this example:

my $child_exit_status = $? >> 8;

but that does not seem to work in macOS 10.13.3.  I had to shift right 10
bits to get zero, and I did this by requiring a Perl module I know to be
loaded in the system, since loading it yielded an un-shifted exit value ==
512.

So, since PDL includes a build of PerlIO::Layers if that module does not
exist, it is indirectly broken. That test needs be be corrected, either by
me, on my system, the maintainer of PerlIO::Layers or a PDL maintainer. How
should we proceed? I will fix my copy and try again to build PDL but what
does the PDL dev group intend to do, if anything?

Except, the test contains the comment:

# this test was generated with Dist::Zilla::Plugin::Test::Compile 2.036

so that tells me I should *not* change the test itself, but some config
file.

Make no mistake, macOS 10.13.3 is a nest of vipers with beaucoup bugs.
10.13 is not 10.12 and many things are broken, including the latest binary
build of PDL for macOS. Unpacking the .dmg yields, among other things,
perldl (home) and perldl (here), neither of which will run. MacOS reports
both files damaged, which to me simply means they were not compiled and
linked with the 10.13 compiler.

Regards,
Will
t.william.schm...@gmail.com




On Thu, Mar 22, 2018 at 4:53 PM, William Schmidt <
t.william.schm...@gmail.com> wrote:

> One more comment and then I'll keep quiet: PDL-Stats-0.75-0 builds
> perfectly, right out of the box on debian 9.3.0. I run it in a VirtualBox
> vm, and no, I can't live with doing all my math work in debian, since most
> of what I do is in macOS. I just can't invest in learning R when I know
> Perl so well, so getting PDL to work in 10.13 is a high priority. In macOS
> the PDL build is referencing PDL-2.018-0. I don't know whether the sources
> in the two files are the same but I assume they are, since both a fresh
> downloads. Another indication PDL on 10.13 has issues.
>
>
>
>
>
>
>
> On Thu, Mar 22, 2018 at 4:35 PM, William Schmidt <
> t.william.schm...@gmail.com> wrote:
>
>> Since I've been told this is not a PDL issue, and I should look to the
>> maker of PerlIO::Layers, I checked deeper into the stderr/stdout output of
>> the PDL build and it too downloads the bits for PerlIO::Layers and attempts
>> to build the module, with the same test error, except it knows how to
>> source the env while the stand-alone build of PerlIO::Layers does not.
>> PERL5OPT is irrelevant since it does not affect builds and I never use it,
>> so it should be an empty value. The test fails with:
>>
>> #   Failed test 'PerlIO/Layers.pm loaded ok'
>> #   at t/00-compile.t line 35.
>> #          got: '512'
>> #     expected: '0'
>>
>> as before. So, this *is* an issue with PDL. I may be guilty of some sort
>> of pilot error but PDL fails, both sudo and as an ordinary user attempting
>> to build into a local filesystem. I tried it both ways, first as myself and
>> then as sudo with the same result. I'm convinced this is an Apple 10.13
>> issue and you folks working on PDL are unaware of the issues Apple created
>> with this release of the OS. I can help sort out these errors but first I
>> need you guys to own up to issues when dealing with 10.13.
>>
>> Will
>>
>>
>>
>>
>> On Thu, Mar 22, 2018 at 4:07 PM, William Schmidt <
>> t.william.schm...@gmail.com> wrote:
>>
>>> I don't like being lectured to about my language and profanity is
>>> perfectly good English to express frustration with an arrogant company, but
>>> I digress. I'm probably much older than you and not one of your students.
>>>
>>> Here is the line from the PDL build log that I captured by redirecting
>>> both stdout and stderr to a file when attempting to build PDL:
>>>
>>> PERL5LIB=/Users/carly/perl5/lib/perl5:/Users/carly/src/perl5/lib
>>>
>>> As you can see, *that* makefile correctly sourced the environment. It
>>> is the build for PerlIO::Layers that doesn't source the environment
>>> correctly. And yes, it is a PDL issue because I'm trying to track down and
>>> correct the errors generated in that build. It doesn't matter that
>>> PerlIO::Layers won't build stand-alone, because I would not be building it
>>> if *PDL did not require it*.  Are you sure, absolutely sure, you're not
>>> just winging it off the top of your head that PDL will build in macOS
>>> 10.13.3? 10.13 is not 10.12, and you must not be a macOS user fighting with
>>> the broken stuff in 10.13 or you would know that.  If you follow macOS bugs
>>> at Apple support you would know the macOS community is up in arms over the
>>> abominable support from Apple for 10.13.bugs. USB 3.0 support is still
>>> broken in 10.13.*, after months out in the wild. If you are not experienced
>>> with 10.13.*, then you don't know what you are talking about, since almost
>>> everything compiled on macOS before 10.3. is broken. The latest binary
>>> build of PDL is also broken, since when you unpack the .dmg file the perldb
>>> (here) and perldb (home) files are both corrupted.  They will not load. If
>>> they had worked as advertised I would not have had to try building PDL from
>>> source.
>>>
>>> Will
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 22, 2018 at 3:14 PM, Derek Lamb <de...@boulder.swri.edu>
>>> wrote:
>>>
>>>> Hi Will,
>>>>
>>>> This doesn't really seem to be a PDL issue.  And you don't say whether
>>>> you've been able to install on prior versions of macOS.  But my
>>>> PerlIO::Layers installed from MacPorts just fine on macOS 10.12.x (Sierra),
>>>> and it doesn't look like MacPorts does anything special to make it work.
>>>> And PerlIO::Layers hasn't been updated in 4 years, so it's probably not a
>>>> recent issue.
>>>>
>>>> All of that suggests that it's something on your end.  The
>>>> PerlIO::Layers test that fails relies on open3 and waitpid, which means
>>>> child processes etc are at work here.  I notice you're trying to install
>>>> with sudo.  Are you installing into a user or a system directory?  If you
>>>> do a 'man perlrun' you can get descriptions of the PERL5LIB and PERL5OPT
>>>> environment variables.  The fact that they are not set here is interesting,
>>>> considering you say you set PERL5LIB in your env.  Is PERL5LIB exported?
>>>> Have you sourced your ~/.profile (or whatever) since setting that, either
>>>> explicitly or by opening a new terminal window?
>>>>
>>>> To be completely pedantic, I would expect to see something like:
>>>>
>>>> export PERL5LIB="/Users/carly/perl5"
>>>>
>>>> in your ~/.profile file. (that assumes some things about what's in that
>>>> directory, but absent an explanation I am just making a guess.)
>>>>
>>>> Derek
>>>>
>>>>
>>>> On Mar 22, 2018, at 12:41 PM, William Schmidt <
>>>> t.william.schm...@gmail.com> wrote:
>>>>
>>>> Hello PDL peeps,
>>>>
>>>> I'm trying to build PDL in macOS 10.13.3 (High Sierra) and am getting a
>>>> build test error in a pre-req, specifically, in PerlIO::Layers. The
>>>> scenario:
>>>>
>>>> sudo cpan install PDL.  # Warning: prerequisite File::Map 0.57 not
>>>> found. There are other pre-req errors but the first one is a deal-killer.
>>>>
>>>> sudo cpan install File::Map  # this build failed to find its pre-req,
>>>> PerlIO::Layers, so it downloaded the bits and attempted to build it. The
>>>> script reported the build was OK, but its tests failed with:
>>>>
>>>> t/00-compile.t ............ 1/1
>>>> #   Failed test 'PerlIO/Layers.pm loaded ok'
>>>> #   at t/00-compile.t line 35.
>>>> #          got: '512'
>>>> #     expected: '0'
>>>>
>>>> File attached of relevant output. Notice that PERL5LIB and PERL5OPT at
>>>> lines 30 and 31 are not resolved. PERL5LIB is set in my env (bash) but I am
>>>> not setting PERL5OPT, whatever that means in this build. If PERL5LIB must
>>>> be resolved, the build script is not pulling it from my env, and if
>>>> PERL5OPT must be set, I need to know what to set it to.
>>>>
>>>> My compiler is:
>>>>
>>>> $ gcc -v
>>>> Configured with: --prefix=/Library/Developer/CommandLineTools/usr
>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>>>> Apple LLVM version 9.0.0 (clang-900.0.39.2)
>>>> Target: x86_64-apple-darwin17.4.0
>>>> Thread model: posix
>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>>>
>>>> Any ideas? (Yes, I know how fucking arrogant Apple is about building
>>>> stuff on its latest OS, but getting PDL to run on my mac is very high
>>>> priority :-)  Why run R (and invest hours and hours learning it) when you
>>>> can run PDL?)
>>>>
>>>> Regards,
>>>> Will Schmidt
>>>> t.william.schm...@gmail.com
>>>>
>>>>
>>>> <PDLbuildErrors>--------------------------------------------
>>>> ----------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
>>>> _________________________________________
>>>> pdl-devel mailing list
>>>> pdl-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>>>>
>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

Reply via email to