I was able to do
$ mv /usr/local/lib /usr/local/lib_bak
$ mv /usr/local/include /usr/local/include_bak
$ mv /usr/local/bin /usr/local/bin_bak
(with sudo) and I was able to successfully install python3-3.6.1 but
then the build failed on pyzmq-17.0.0b3. I'm attaching the log but the
problem
On Friday, April 27, 2018 at 4:07:52 PM UTC-7, Samuel Lelievre wrote:
>
>
>
> 2018-04-27 22:18 GMT+02:00 John H Palmieri:
> >
> > On Friday, April 27, 2018 at 12:56:37 PM UTC-7, Dima Pasechnik wrote:
> >>
> >> On Friday, April 27, 2018 at 8:16:32 PM UTC+1, Christelle Vincent wrote:
> >>>
> >>>
2018-04-27 22:18 GMT+02:00 John H Palmieri:
>
> On Friday, April 27, 2018 at 12:56:37 PM UTC-7, Dima Pasechnik wrote:
>>
>> On Friday, April 27, 2018 at 8:16:32 PM UTC+1, Christelle Vincent wrote:
>>>
>>> It says: Should I install the database then?
>>
>> that's OK to do so.
>>
>> I bet the
On Friday, April 27, 2018 at 12:56:37 PM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Friday, April 27, 2018 at 8:16:32 PM UTC+1, Christelle Vincent wrote:
>>
>> It says: Should I install the database then?
>>
>
> that's OK to do so.
>
> I bet the offending library is in /usr/local
> (headers in
On Friday, April 27, 2018 at 8:16:32 PM UTC+1, Christelle Vincent wrote:
>
> It says: Should I install the database then?
>
that's OK to do so.
I bet the offending library is in /usr/local
(headers in /usr/local/include, the library in /usr/local/lib, have a look)
Move them out of the way.
It says: Should I install the database then?
WARNING: The locate database (/var/db/locate.database) does not exist.
To create the database, run the following command:
sudo launchctl load -w
/System/Library/LaunchDaemons/com.apple.locate.plist
Please be aware that the database can take
One difference between your OS X installation and mine: near the start of
your log, I see
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
whereas these say "no" on my machine. What does "locate libintl" say (when you
run it from the
It still didn't work. To recap, this time I tried to install sage-8.2.rc4,
and first I ran
$ export
PATH='/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin'
Make still failed at installing python3-3.6.1.p1, the log looks the same
but I am attaching it again in case I'm missing
Just started over with Samuel's instructions, will update when it's done!
On Friday, April 27, 2018 at 8:57:36 AM UTC-4, Samuel Lelievre wrote:
>
> Tips for building under macOS:
>
> - Check the number of cores you have with the command
>
> $ sysctl -n hw.ncpu
>
> - Before running `make`,
Tips for building under macOS:
- Check the number of cores you have with the command
$ sysctl -n hw.ncpu
- Before running `make`, run the following two lines:
$ export
PATH='/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin'
(this is to remove /usr/local/bin from
You have /usr/local/bin first (or at all) in your PATH. This might be asking
for trouble while building/running Sage, depending upon what you have installed
there.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group
I don't know enough about OpenSSL to weigh in on that part of the
discussion. Maybe that would make it impossible to download some python3
package?
In any case, I am attaching for Dima (thank you for all your help by the
way) the output of set. I also downloaded and just started making
More precisely, the shell simply interprets
if ![ -z "$OPENSSL_INCLUDE" ]
as
if false
so the typo just breaks support for "OPENSSL_INCLUDE".
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
On 2018-04-26 14:45, Erik Bray wrote:
Line 66 (really line 34 in the unwrapped sources) of spkg-build for
Python 3 shows:
if ![ -z "$OPENSSL_INCLUDE" ]; then
I think that's clearly a typo. Looks like it's been there for a long
time too.
Since #21944 for the record. The question is:
Vincent Delecroix wrote:
> That does not prevent us to normalize for let say: __repr__() ,
> numerator(), denominator(). Is there any reasonable rule to choose
> when to and when not to normalize? For QQ itself, GMP does normalize
> all the time.
Just to be certain that we are talking about the
On 23/04/2018 19:35, Marc Mezzarobba wrote:
John Cremona wrote:
This is simpler than writing numerator and denominator as a rational
times a primitive integral polynomial, though that is probably what
users would prefer.
And (at least in my limited experience), for rational fractions over
16 matches
Mail list logo
