Re: [Bug-apl] compile error location of malloc.h

[Louis de Forcrand]

I’m sorry to say that this bug is (or was last time I checked) in release 1.6.

As it makes it more complicated to compile it on OS X maybe it would be

better to fix release 1.6 for people new to GNU APL? Of course it might

also be better to wait a little while and include some other fixes in order

to make the update worth the effort.

Cheers,

Louis

On 31 Aug 2016, at 03:35, Blake McBride <address@hidden> wrote:

Here is a +1 for keeping it as straight C as possible.

Blake

On Tue, Aug 30, 2016 at 4:17 AM, Juergen Sauermann <address@hidden> wrote:

Hi Xiao-Yong,

in principle you are right. However I have avoided to use the C++ counterparts of the standard C include files
so far  because some of them produce compile errors like this:

/usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support
for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11
or -std=gnu++11 compiler options.

and I was afraid that this would negatively impact the portability of GNU APL without giving an advantage.

/// Jürgen

On 08/29/2016 11:21 PM, Xiao-Yong Jin wrote:

There is nothing wrong using <stdlib.h>, but in C++ the standard way is
  #include<cstdlib>
and call
  std::malloc
and its friends.

On Aug 29, 2016, at 4:43 AM, Juergen Sauermann <address@hiddende> wrote:

Hi,

thanks, fixed in SVN 794.

I went for <stdlib.h> because that is what the malloc manpage says.

Currently <stdlib.h> is aleady #included by Common.hh but that may change.
Therefore I believe that it is cleaner to #include it again.

/// Jürgen


On 08/29/2016 07:21 AM, Elias Mårtenson wrote:

They are, but if they are not found in the local directory, they are also searched for in the system directories.

That said, in this case using the angle brackets is the correct thing to use.

On 29 August 2016 at 13:08, Christian Robert <address@hidden> wrote:
that should read:

#include <malloc.h>

or better

#include <stdlib.h>

things in double quotes are searched in local directory by default and not in system.

Xtian.


On 2016-08-28 23:42, Xiao-Yong Jin wrote:
    LApack.cc:21:20: fatal error: malloc.h: No such file or directory
     #include "malloc.h"
                    ^
    compilation terminated.

Under OS X, it’s in /usr/include/malloc/malloc.h

Is it actually needed?  The code compiles fine without the #include.

Best,
Xiao-Yong