Hi Will-
I understand your frustration in not being able to
build/install PDL.
When we/I say it is not a PDL bug, we don't mean
that the bug doesn't affect PDL as it clearly does
since we require File::Map which requires PerlIO::Layers.
It means that the fix is not in the PDL code and that a
bug report and resolution would be made with the
PerlIO::Layers developer(s).
That said, this is clearly a build problem for PDL
and MacOS 10.13.3. Were you able to try the
build work around I suggested? That should allow
PDL to build and install. The simplest way is to
use a CPAN client such as cpan or cpanm... to
install all the dependencies of PDL (listed in the
DEPENDENCIES file in the PDL-2.018 distribution).
Then download and extract the PDL-2.018 sources
and edit the Makefile.PL to delete the line requiring
File::Map (search for File::Map to get there). At
that point a manual build should be possible by
running:
perl Makefile.PL <your specific extra args here>
make
make test
make install
Hope this helps,
Chris
On Thu, Mar 22, 2018 at 8:19 PM, William Schmidt <
t.william.schm...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
