PDL 2.083 build errors #438
Comments
|
Since posting my build report I found HDF-4.2.16 for Apple clang 10,0.0 and gfortran 6.3.0 at https://portal.hdfgroup.org/display/support/HDF+4.2.16#files and was able to successfully execute the shell script HDF-4.2.16-Darwin.sh. This script seemed to execute without error and built a huge tree of files including libdf.a. The question now is, what do I do with this stuff to make it available to cpanm building PDL? In other words, where do I put this stuff, or a link to it OTHER THAN IN THE macOS SYSTEM DIRECTORIES. I depend on perlbrew to keep my private, non-Apple Perl implementations current. Apple owns and uses the Perl that came with the OS and I prefer to not touch it, if possible. |
|
In order to make this work, you would need to have Alien::HDF4 return suitable C compiler flags for the location you've got HDF installed in. A "proper" Alien package these days, built on top of Alien::Build, would make this very easy, using a "share install". Something like an explanation of share vs system can be seen at the docs' most relevant section. If you were minded to make a full, "proper" Alien::Build-using Alien::HDF4 instead of the hacked-together thing I made, that document will help you do so, and would probably not be hard. It would also be a great contribution! If you are so minded, please put it together and make a pull-request on the relevant repository. For your purposes, you could simply edit your installed Alien::HDF4::Install::Files module (locate it with Keeping up to date with the latest MacOS might cause you some short-term disruption, but would avoid nearly all of the problems you are experiencing, and would also close various security holes. I will not support an old, insecure, obsolete version of MacOS, nor of clang, but I will be pleased to accept patches that make those work. |
|
After I posted this thread I found and successfully built Alien::HDF4 with
my existing clang. I then continued to troubleshoot the failing PDL 2.083
build and I discovered a macro in pdlcore.c that exceeded the length of
macro #defines in two versions of clang. I verified that that macro was
causing the segmentation fault by carefully moving through the macro with
#if 0...#endif assertions and successfully compiled that file until very
near the end of the macro definition. The C standard says a conforming
compiler must accept a macro of at least 4096 bytes. C++ has no such
limitation. Some reporters cite 4095 but + or - 1 byte is immaterial,
Some compilers accept #defines longer than 4096 - your mileage may vary,
but my two versions of clang barf on that macro. The PDL dev community may
not consider this issue to be a bug. I do. It is totally arrogant to
insist that everyone always maintain the latest version of some proprietary
vendor's (such as Apple) technology. That is the perpetual upgrade
treadmill, does nothing but put money in that vendor's pocket and to opine
that upgrading is trivial is bullshit. It is also contrary to the
philosophy of open-source. Once a year I reread *The Cathedral and the
Bazaar*, to make sure I don't forget what open source is all about.; (hint,
hint). It is none of anyone's business but my Apple hardware cannot
support the latest macOS, and my computing infrastructure is too expensive
for a retired SE to replace. This bug prompted me to take a look at R in
both Eclipse and RStudio, and it looks like my research can be done in R at
least as well as it can be done in Perl. My first choice of a dev platform
is always Perl with C, because of 30+ years of hacking Perl, but I am never
afraid to learn something new.
I documented my test results to ***@***.*** and
to ***@***.*** but have as yet heard nothing
back. If there is a better email address to which to send my debug
research please provide. I now know I can modify that macro definition to
shorten it by carefully renaming local variables, such as cursor -> c; a
kludge within a kludge (that macro's author calls it a kludge - I guess he
knows of what he speaks. But that means every time I upgrade PDL I would
have to make those same changes. That is not something I'm prepared to
do. I'll do it once as a proof of concept, but only once.
Regards,
T. William Schmidt
…On Sat, May 20, 2023 at 8:27 AM mohawk2 ***@***.***> wrote:
In order to make this work, you would need to have Alien::HDF4 return
suitable C compiler flags for the location you've got HDF installed in. A
"proper" Alien package these days, built on top of Alien::Build, would make
this very easy, using a "share install".
Something like an explanation of share vs system can be seen at the docs' most
relevant section
<https://metacpan.org/dist/Alien-Build/view/lib/Alien/Build/Manual/AlienAuthor.pod#A-note-about-dynamic-vs.-static-libraries>.
If you were minded to make a full, "proper" Alien::Build-using Alien::HDF4
instead of the hacked-together thing I made, that document will help you do
so, and would probably not be hard. It would also be a great contribution!
If you are so minded, please put it together and make a pull-request on the
relevant repository.
For your purposes, you could simply edit your installed
Alien::HDF4::Install::Files module (locate it with perldoc -l
Alien::HDF4::Install::Files) to return appropriate things.
Keeping up to date with the latest MacOS might cause you some short-term
disruption, but would avoid nearly all of the problems you are
experiencing, and would also close various security holes. I will not
support an old, insecure, obsolete version of MacOS, nor of clang, but I
will be pleased to accept patches that make those work.
—
Reply to this email directly, view it on GitHub
<#438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI4GMDCGG3EQUXD6VSEC353XHDBD7ANCNFSM6AAAAAAYCNB2O4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Interesting find re: the C standard macro length. However, wouldn't a truly open-source-informed approach be to submit a patch/ pull request that fixes the macro in question? (I.e. a couple of appropriately parametrised sub-macros that get incorporated in the currently huge one ought to do it. Hint hint). |
|
I agree, totally, but to refactor that macro, #define PDL_*KLUDGE*_COPY_X(X,
datatype_out, ctype_out, ppsym_out, ...) \
into several non-kludge macros requires an in-depth knowledge of PDL
internals, the internal structure of PDL objects and all those variables
that are passed back and forth between Perl and C. I have no such
knowledge and it would probably take weeks, perhaps months of study if I
had up-to-date PDL design docs. Think of how much effort the current dev
team has invested in learning PDL internals to get it to where it is
today. My solution is nothing but a quick and dirty way to get around the
fact that the dev team is not sensitive to the variations always present in
C compilers. I assume I can fix my copy of pdlcore.c to get the latest PDL
running, report my findings and the well-established dev team would
refactor that macro. Anyone who has ever looked at non-trivial .h files
meant to be platform and compiler independent has seen constructions like:
#if _MSDOS
...
#elif _MACOSX
...
#elif _MVS
...
#endif
You can't escape this dilemma if your intent is to be totally transparent
and support as many operating environments as possible. Apple, a
proprietary company can say, and does, *"screw you if you won't or can't
upgrade. we have a policy to orphan our or anyone else's software,
whenever we feel like it, whenever maintaining the old gets too expensive."*
In the mid-nineties I once argued to a client not to use J++, Microsoft's
implementation of Java, in favor of vanilla Java, even though Sun's and
then Oracle's run-times were slower than Microsoft's. I warned this client
that Microsoft had an internal policy of "*Embrace, extend, and extinguish*".
At the time Microsoft had promised to release as open source the APIs used
to build their runtime for NT. Alas, this was a lie; they never did.
Instead, they foisted C# onto a non-open-source public. The client ignored
my advice and went with J++ for a major project and two years later MS
discontinued J++. I relate this story only to underscore how truly
important is platform independence. It is interesting to note that
PDL-2.083 requires at least Perl 5.10, a truly old Perl, yet expects PDL
users to have the very latest C compilers. I run Perl 5.30.2 and it isn't
even the latest stable Perl, 5.36.1.
I once worked 5 years for a company in Chicago, Performix, that was 100%
open source except for DB2, which ran alongside MySQL. DB2 runs on Linux
because IBM actually does get open-source, or at least the need to be
platform independent. That was the best working experience of my life even
though I wound up retiring from Google (definitely *not* the best.) I
would love to debate open-source philosophy with any and all but in truth,
I am doing applied math research and teaching with a group of motivated but
disadvantaged young adults. I can't take the time to learn PDL internals
just to fix this macro.
Regards,
Will (perlboy and sometimes perlboy_emeritus)
…On Sat, May 20, 2023 at 11:32 AM PerlSAP ***@***.***> wrote:
Interesting find re: the C standard macro length.
However, wouldn't a truly open-source-informed approach be to submit a
patch/ pull request that fixes the macro in question? (I.e. a couple of
appropriately parametrised sub-macros that get incorporated in the
currently huge one ought to do it. Hint hint).
—
Reply to this email directly, view it on GitHub
<#438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI4GMDALW67ZXG2F45UHM63XHDW3FANCNFSM6AAAAAAYCNB2O4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I am sure it has taken less time for me to write and run this code than it took @perlboy-emeritus to type in his humble-brag life story (whose relevance to this issue I cannot fathom): $/=undef;
$_=<>;
push @found, [$1,$2]
while /
^
[ \t]*
\#[ \t]*
define[ \t]+
([a-zA-Z][^\(\s]+)
[ \t]*\(.*?\)[ \t]*
(.*?[^\\]\n)
/gmsx;
#use Data::Dumper; print Dumper \@found;
print "$_->[0]: ", length($_->[1]), "\n" for @found;which when run on |
|
And the deep, cross-platform refactoring of the relevant macro by removing some whitespace has now reduced it to 3957 characters, which took <15 mins. |
|
Now released as 2.084. |
|
Done, thank you,
$ cpanm -i PDL
PDL is up to date. (2.084)
but only after I added paths to HDF4 libs and includes to perldl.conf and
made my own changes to pdlcore.c, to wit:
WITH_HDF => 1, # Leave it up to PDL to decide; no not leave it
up to PDL!
HDF_LIBS => '/opt/HDF_Group/HDF/lib',
HDF_INC => '/opt/HDF_Group/HDF/include', #make this obvious
these are NOT from Apple
if(i >= dest_dims[ndims-1-level]) return undef_count; \
/* pad the rest of this dim to zero if there are not enough elements in
the source PDL... */ \
int c, t; \
c = i*stride; \
t = dest_dims[ndims-1-level]*stride; \
undef_count += t-c; \
for (; c<t; c++) dest_data[cursor] = undefval; \
return undef_count; \
}
I don't know what you did to shorten that macro, I read your release note,
but I still had to manually make these edits. Unfortunately, after a
successful install the breadcrumbs get deleted. I saved these two BEFORE
make. I'm satisfied if you are, and I'll inspect any pdlcore.c file that
comes down in the future. Just out of curiosity, I would love to see a
diff of pdlcore.c.2.083 and pdlcore.c.2.084. Perhaps you could attach
pdlcore.c.2.083 to a return email to enlighten me? And I see myself as an
unofficial clang build tester for future PDL builds, assuming my arrogance
does not offend anyone too much :-). I'm pushy enough that I usually get
what I want...
Thanks again.
…On Sun, May 21, 2023 at 11:35 AM mohawk2 ***@***.***> wrote:
Now released as 2.084.
—
Reply to this email directly, view it on GitHub
<#438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI4GMDE6V6SOKIFMOMU5NRTXHI75FANCNFSM6AAAAAAYCNB2O4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hey mokawk2,
PDL_KLUDGE_COPY_X: 4884
Your words not mine.
Isn't 4884 > 4096?
I told those anecdotes as examples of walking the walk rather than
talking the talk :-). If the length of
PDL_KLUDGE_COPY_X is really 4884, that explains why I had to tweak my
copy to get it to compile.
On Sun, May 21, 2023 at 2:36 PM William Schmidt ***@***.***>
wrote:
… Done, thank you,
$ cpanm -i PDL
PDL is up to date. (2.084)
but only after I added paths to HDF4 libs and includes to perldl.conf and
made my own changes to pdlcore.c, to wit:
WITH_HDF => 1, # Leave it up to PDL to decide; no not leave it
up to PDL!
HDF_LIBS => '/opt/HDF_Group/HDF/lib',
HDF_INC => '/opt/HDF_Group/HDF/include', #make this obvious
these are NOT from Apple
if(i >= dest_dims[ndims-1-level]) return undef_count; \
/* pad the rest of this dim to zero if there are not enough elements in
the source PDL... */ \
int c, t; \
c = i*stride; \
t = dest_dims[ndims-1-level]*stride; \
undef_count += t-c; \
for (; c<t; c++) dest_data[cursor] = undefval; \
return undef_count; \
}
I don't know what you did to shorten that macro, I read your release note,
but I still had to manually make these edits. Unfortunately, after a
successful install the breadcrumbs get deleted. I saved these two BEFORE
make. I'm satisfied if you are, and I'll inspect any pdlcore.c file that
comes down in the future. Just out of curiosity, I would love to see a
diff of pdlcore.c.2.083 and pdlcore.c.2.084. Perhaps you could attach
pdlcore.c.2.083 to a return email to enlighten me? And I see myself as an
unofficial clang build tester for future PDL builds, assuming my arrogance
does not offend anyone too much :-). I'm pushy enough that I usually get
what I want...
Thanks again.
On Sun, May 21, 2023 at 11:35 AM mohawk2 ***@***.***> wrote:
> Now released as 2.084.
>
> —
> Reply to this email directly, view it on GitHub
> <#438 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AI4GMDE6V6SOKIFMOMU5NRTXHI75FANCNFSM6AAAAAAYCNB2O4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Hey again mokawk2; once more then no more...
Removing spaces tabs and comments with that little Perl expression was a
waste of time and effort, and the futile release of a PDL version. Lexical
analysis, the first pass of C compilation does that for you when it
tokenizes the .c source file. There is no token for white space in the C
grammar. The lexer merely uses it as a separator. Therefore, if the
compiler is enforcing a macro definition length limitation, it is
determined from the tokens themselves and/or the op codes mapped to those
token types. The only way to actually shorten the length of the macro is
to do something like what I did, namely *change cursor to c and target to t*,
or refactor the macro. Removing white space accomplishes nothing.
Compilation of pdlcore.c 2.083 and 2.084 was identical, a segmentation
fault, until I fixed it.
See lexical analysis in Wikipedia, to wit:
Consider this expression in the C
<https://en.wikipedia.org/wiki/C_(programming_language)> programming
language:
x = a + b * 2;
The lexical analysis of this expression yields the following sequence of
tokens:
[(identifier, x), (operator, =), (identifier, a), (operator, +),
(identifier, b), (operator, *), (literal, 2), (separator, ;)]
Cheers...
On Sun, May 21, 2023 at 6:51 PM William Schmidt ***@***.***>
wrote:
… Hey mokawk2,
PDL_KLUDGE_COPY_X: 4884
Your words not mine.
Isn't 4884 > 4096?
I told those anecdotes as examples of walking the walk rather than talking the talk :-). If the length of
PDL_KLUDGE_COPY_X is really 4884, that explains why I had to tweak my copy to get it to compile.
On Sun, May 21, 2023 at 2:36 PM William Schmidt <
***@***.***> wrote:
> Done, thank you,
> $ cpanm -i PDL
> PDL is up to date. (2.084)
>
> but only after I added paths to HDF4 libs and includes to perldl.conf and
> made my own changes to pdlcore.c, to wit:
>
> WITH_HDF => 1, # Leave it up to PDL to decide; no not leave
> it up to PDL!
> HDF_LIBS => '/opt/HDF_Group/HDF/lib',
> HDF_INC => '/opt/HDF_Group/HDF/include', #make this obvious
> these are NOT from Apple
>
> if(i >= dest_dims[ndims-1-level]) return undef_count; \
> /* pad the rest of this dim to zero if there are not enough elements in
> the source PDL... */ \
> int c, t; \
> c = i*stride; \
> t = dest_dims[ndims-1-level]*stride; \
> undef_count += t-c; \
> for (; c<t; c++) dest_data[cursor] = undefval; \
> return undef_count; \
> }
>
> I don't know what you did to shorten that macro, I read your release
> note, but I still had to manually make these edits. Unfortunately, after a
> successful install the breadcrumbs get deleted. I saved these two BEFORE
> make. I'm satisfied if you are, and I'll inspect any pdlcore.c file that
> comes down in the future. Just out of curiosity, I would love to see a
> diff of pdlcore.c.2.083 and pdlcore.c.2.084. Perhaps you could attach
> pdlcore.c.2.083 to a return email to enlighten me? And I see myself as an
> unofficial clang build tester for future PDL builds, assuming my arrogance
> does not offend anyone too much :-). I'm pushy enough that I usually get
> what I want...
>
> Thanks again.
>
>
>
>
>
> On Sun, May 21, 2023 at 11:35 AM mohawk2 ***@***.***>
> wrote:
>
>> Now released as 2.084.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#438 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AI4GMDE6V6SOKIFMOMU5NRTXHI75FANCNFSM6AAAAAAYCNB2O4>
>> .
>> You are receiving this because you were mentioned.Message ID:
>> ***@***.***>
>>
>
|
|
A real software engineer would:
|
|
Yo mohawk2,
You really need to review C compilation, because you just don't get it.
Have not had a great deal of time to spend on this issue (looking at R and
Python as PDL alternatives; both looking good) but here is what I did:
- Downloaded fresh copies of PDL 2,083 and 2,084 but did not build them,
except to verify they both segmentation fault, as before;
- Used *find* with *exec* to move all **.h* files to a test directory
(necessary since *pdlcore.c* will not compile or preprocess without them;
- Preprocessed pdlcore.c with *gcc -E pdlcore.c > stuff* for each
version of that file;
- Isolated *pdl_kludge_copy_A* thru *pdl_kludge_copy_U* (I think U, in
two physical lines) in both *stuffs* and diffed them. Differences are
paired braces { ... { ... } }, or not;
- There are only 20 bytes difference in these two macro expansions, and
guess what, those fewer bytes are because you removed some extra braces
that you must have decided were redundant, not because you removed white
space. Imagine that, you supposedly stripped out white space but failed to
explain why you needed to remove those braces.
Here's the bottom line; I asserted without proof that removing white space
does absolutely nothing to shorten the length of macro expansion in C in
two versions of clang. Now I have proved that assertion and also detected
the removal of braces in 2,084. My kludge within a kludge tweek of target
to t and count to c does compile, but it only serves to prove that macro
needs to be refactored. That's your job, not mine. My job is to report
bugs, especially *build bugs* when I find them. If you decide to fix this
I'll return to PDL but this experience of arguing with you over nits is no
longer worth my time, since those other alternatives work just as well
without an attitude on the part of the PDL monger.
Cheers,
Will Schmidt
Regards,
Will
…On Sun, May 28, 2023 at 7:48 PM mohawk2 ***@***.***> wrote:
A real software engineer would:
- know my Perl expression does not modify anything
- realise C macro length includes whitespace
- know that CPP operates before any lexing stage, rendering the
"whitespace token" points above irrelevant
- know how to use git to see different versions of files
- be capable of capturing exactly the before-and-after versions of any
files they modified in building/installing a piece of software
- strip any such changes down to the bare minimum to achieve the
change between success and failure
- be able to submit such changes as a pull request
—
Reply to this email directly, view it on GitHub
<#438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI4GMDAXO6W7ZCUEFE724P3XIPW4TANCNFSM6AAAAAAYCNB2O4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
mohawk2,
I extracted this fragment from the 2,083 version of *pdlcore.c*, because it
is different from the 2,084 version. The braces appear to denote only
documentation and their absence is probably harmless. One typical use of
paired braces within C code is to hide a previous local variable. Within
the braces, say *plevel,* is local within the braces context and hides a
previous version of a variable with the same name. Only a full regression
test can determine whether the absence of these braces have any effect on
execution. I assume after you made the white space changes in 2,084 the
code passed all tests, so I'll give you the benefit of the doubt.
*{ \*
PDL_Indx limit = ( \
(*plevel* >= 0 && \
(source_pdl->ndims - 1 - plevel >= 0) \
) \
? (source_pdl->dims[ source_pdl->ndims-1-plevel ]) \
: 1 \
* ); \*
for(i=0; i < limit ; i++) *{ \*
undef_count += pdl_kludge_copy_ ## ppsym_out(0, dest_data +
stride * i, \
dest_dims, \
ndims, \
level+1, \
stride /
((dest_dims[ndims-2-level]) ? (dest_dims[ndims-2-level]) : 1), \
source_pdl, \
plevel+1, \
((PDL_Byte *) source_data) +
source_pdl->dimincs[source_pdl->ndims-1-plevel] * i *
pdl_howbig(source_pdl->datatype), \
undefval, \
dest_pdl \
); \
* } /* end of kludge_copy recursion loop */ \ } /* end of recursion
convenience block */ \*
So, as we can see from preprocessing *pdlcore.c *with *gcc -E*, the 2,083
and 2,084 versions of *pdlcore.c* are identical other than for these
braces, which is why they both segmentation fault when compiled. Deleting
these braces yield a net 20 byte reduction in the size of the preprocessed
output. And the preprocessed outputs are otherwise identical despite the
elimination of white space.
I'm not trying to pick a fight with anyone. My only point is to note that
*pdlcore.c* as currently implemented is a latent bomb waiting to go off.
You owe it to PDL users, especially on macOS, who may be great
mathematicians but lack my debugging skills to fix this problem by
refactoring that code so it is not compiler length limited. How you do it
is none of my business.
Will
On Tue, Jun 13, 2023 at 6:23 PM William Schmidt ***@***.***>
wrote:
… Yo mohawk2,
You really need to review C compilation, because you just don't get it.
Have not had a great deal of time to spend on this issue (looking at R and
Python as PDL alternatives; both looking good) but here is what I did:
- Downloaded fresh copies of PDL 2,083 and 2,084 but did not build
them, except to verify they both segmentation fault, as before;
- Used *find* with *exec* to move all **.h* files to a test directory
(necessary since *pdlcore.c* will not compile or preprocess without
them;
- Preprocessed pdlcore.c with *gcc -E pdlcore.c > stuff* for each
version of that file;
- Isolated *pdl_kludge_copy_A* thru *pdl_kludge_copy_U* (I think U, in
two physical lines) in both *stuffs* and diffed them. Differences are
paired braces { ... { ... } }, or not;
- There are only 20 bytes difference in these two macro expansions,
and guess what, those fewer bytes are because you removed some extra braces
that you must have decided were redundant, not because you removed white
space. Imagine that, you supposedly stripped out white space but failed to
explain why you needed to remove those braces.
Here's the bottom line; I asserted without proof that removing white
space does absolutely nothing to shorten the length of macro expansion in C
in two versions of clang. Now I have proved that assertion and also
detected the removal of braces in 2,084. My kludge within a kludge tweek
of target to t and count to c does compile, but it only serves to prove
that macro needs to be refactored. That's your job, not mine. My job is
to report bugs, especially *build bugs* when I find them. If you decide
to fix this I'll return to PDL but this experience of arguing with you over
nits is no longer worth my time, since those other alternatives work just
as well without an attitude on the part of the PDL monger.
Cheers,
Will Schmidt
Regards,
Will
On Sun, May 28, 2023 at 7:48 PM mohawk2 ***@***.***> wrote:
> A real software engineer would:
>
> - know my Perl expression does not modify anything
> - realise C macro length includes whitespace
> - know that CPP operates before any lexing stage, rendering the
> "whitespace token" points above irrelevant
> - know how to use git to see different versions of files
> - be capable of capturing exactly the before-and-after versions of
> any files they modified in building/installing a piece of software
> - strip any such changes down to the bare minimum to achieve the
> change between success and failure
> - be able to submit such changes as a pull request
>
> —
> Reply to this email directly, view it on GitHub
> <#438 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AI4GMDAXO6W7ZCUEFE724P3XIPW4TANCNFSM6AAAAAAYCNB2O4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been trying for days to upgrade PDL from 2.021 to 2.083, and so far, nothing, including advice from ej_zg has resolved my issue, a segmentation fault in compilation of pdlcore.c, to wit:
I am running Perl
on macOS 10.13.6. Per ej_zg "The segfault you show below is from a bug in that version of clang. Upgrade xcode and it should work.
libdf is part of HDF4, and the Alien package exists to wrap knowledge about that. PDL should install and work fine if HDF4 isn't present. "
I was running Xcode 9.2. I've upgraded command line tools twice, to 9.4.1 and then 10.1 but PDL refuses to build.
When I upgrade Alien my package is up to date, but I am still missing libdf.a, and without that library HDF4 will just not build. I am now without options as to how to get this or any older versions (if I could even find them) of PDL to build. Please don't suggest upgrading macOS just to get the latest PDL. That would cost me days of work fetching, building and/or patching other essential software I must have. It ought not to be this difficult to do a simple version upgrade.
Any help would be much appreciated.
The text was updated successfully, but these errors were encountered: