Build fails on OSX 10.6.4

62 views
Skip to first unread message

Jon

unread,
Nov 12, 2010, 11:22:55 PM11/12/10
to anic, Mike Wilber
I found this project from Hacker New. Very interesting and cool, I've
never seen a language like it before. I cloned the repo and fired up
make and then I hit this road block

Building main executable...
src/types.cpp: In member function ‘TypeStatus::operator uintptr_t()
const’:
src/types.cpp:1514: error: cast from ‘Type*’ to ‘unsigned int’ loses
precision
make: *** [anic] Error 1

my gcc version is i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1
I poked at the wiki and the list archive but couldn't find any mac
specific instructions. I poked at the repo and failed to find any mac
branches/ tags. I reverted a couple of times and tried to recompile.

I then gave up and switched to debian were the project complies just
fine and dandy. I wiped up a hello world.
"Hello, World" ->std.out
Then I ran ./anic helloworld.txt -o a.out -v
Which compiles according to the compiler output but when I run a.out I
don't get any ouput. And so I am a little stuck... Anyways keep up the
good work I look forward to following this project.
-Jon

Daniel Kersten

unread,
Nov 13, 2010, 11:25:28 AM11/13/10
to par...@gmail.com, anic, Mike Wilber
Hi Jon, welcome to the group.

On 13 November 2010 04:22, Jon <par...@gmail.com> wrote:
> I found this project from Hacker New. Very interesting and cool, I've
> never seen a language like it before. I cloned the repo and fired up
> make and then I hit this road block
>
> Building main executable...
> src/types.cpp: In member function ‘TypeStatus::operator uintptr_t()
> const’:
> src/types.cpp:1514: error: cast from ‘Type*’ to ‘unsigned int’ loses
> precision
> make: *** [anic] Error 1

This seems to be an OS X specific problem as it compiles fine on Linux
and Windows. I don't know if Adrian has tried testing it on OS X at
all yet. I haven't anyway.

The problem is this line of code:
TypeStatus::operator uintptr_t() const {return (unsigned int)type;}

type's datatype is Type*, it appears that it won't let you cast a
pointer to an unisnged int. My guess is because OS X is 64bit and
everyone else has only used 32bit systems? Casting a 64bit pointer to
a 32bit unsigned int would indeed "lose precision". Maybe you can tell
your compiler to not treat warnings as errors? Alternatively you could
try casting to a 'unsigned long long' or something like that instead.

>
> my gcc version is i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1
> I poked at the wiki and the list archive but couldn't find any mac
> specific instructions. I poked at the repo and failed to find any mac
> branches/ tags. I reverted a couple of times and tried to recompile.

As far as I know, no effort has yet been made to compile under mac.

>
> I then gave up and switched to debian were the project complies just
> fine and dandy. I wiped up a hello world.
>  "Hello, World" ->std.out
> Then I ran ./anic helloworld.txt -o a.out -v
> Which compiles according to the compiler output but when I run a.out I
> don't get any ouput. And so I am a little stuck... Anyways keep up the
> good work I look forward to following this project.

As has been mentioned on the list a number of times already, this is
very much the expected behaviour right now. The compiler is still an
(early) work in progress and code generation is not yet implemented,
so the output file will be empty. I was supposed to implement basic
codegen a few months ago, but other work kinda took over my life for a
while. Since Adrian is really quiet at the moment, I suspect hes in a
similar situation.

I will certainly let the list know when I finally get around to
finishing the codegen stuff I started in the summer, but I can't
commit to any specific "release date" right now. Of course, if someone
else wanted to tackle it... ;-)

> -Jon
>
>

Regards,
Dan.

Tianyi Cui

unread,
Nov 13, 2010, 5:31:55 PM11/13/10
to anic
The build error can be fixed using this patch from AUR:
http://aur.archlinux.org/packages/anic-hg/anic-hg/uintptr.patch

But the anic binary on my OS X 10.6 generates empty output files. It's
like this:

$ cat a.ani
"Hello, World!" ->std.out
$ ./anic a.ani
$ ls -l a.out
-rw-r--r-- 1 tianyi wheel 0 2010-11-14 06:25 a.out

The size of a.out is 0. I'm not sure why. I tried build it both 32-bit
and 64-bit and the outputs are the same.

The output of ./anic -v a.ani is:

anic: verbose output enabled.

anic: lexing file 'a.ani'....
[SQUOTE Hello, World! (1,1)] [RARROW -> (1,17)] [ID std (1,19)]
[PERIOD . (1,22)] [ID out (1,23)] [END EOF (0,0)]
anic: successfully lexed file 'a.ani'.

anic: parsing file 'a.ani'....
SHIFT 0 -> 65 [SQUOTE]
REDUCE 65 -> 50 <PrimLiteral>
REDUCE 50 -> 40 <Node>
REDUCE 40 -> 36 <TypedStaticTerm>
REDUCE 36 -> 25 <StaticTerm>
REDUCE 25 -> 13 <SimpleTerm>
REDUCE 13 -> 10 <ClosedTerm>
REDUCE 10 -> 7 <Term>
SHIFT 7 -> 33 [RARROW]
SHIFT 33 -> 95 [ID]
SHIFT 95 -> 99 [PERIOD]
SHIFT 99 -> 168 [ID]
REDUCE 168 -> 261 <NonArrayedIdentifierSuffix>
REDUCE 261 -> 98 <NonArrayedIdentifierSuffix>
REDUCE 98 -> 44 <NonArrayedIdentifier>
REDUCE 44 -> 114 <Node>
REDUCE 114 -> 22 <Send>
REDUCE 22 -> 12 <DynamicTerm>
REDUCE 12 -> 94 <Term>
REDUCE 94 -> 163 <Terms>
REDUCE 163 -> 93 <Terms>
REDUCE 93 -> 5 <NonEmptyTerms>
REDUCE 5 -> 3 <LastPipe>
REDUCE 3 -> 2 <Pipes>
REDUCE 2 -> 1 <Program>
ACCEPT
anic: successfully parsed file 'a.ani'.

anic: mapping semantics....
anic: building symbol tree....
anic: tracing data flow....
| {}
|---bool : bool <FRE>
|---char : char <FRE>
|---false : bool\ <FRE>
|---float : float <FRE>
|---int : int <FRE>
|---std : std\ <FRE>
| |---delay : [int --> null]\ <FRE>
| |---err : {
| =[--> string]
| }[] <FRE>
| |---gen : [int --> int\\]\ <FRE>
| |---inChar : char\ <FRE>
| |---inFloat : float\ <FRE>
| |---inInt : int\ <FRE>
| |---inString : string\ <FRE>
| |---out : {
| =[--> string]
| }[] <FRE>
| |---randInt : int\ <FRE>
|---string : string <FRE>
|---true : bool\ <FRE>
anic: successfully mapped semantics.

anic: generating code dump....
anic: successfully generated code dump.

Tianyi Cui

On Nov 14, 12:25 am, Daniel Kersten <dkers...@gmail.com> wrote:
> Hi Jon, welcome to the group.
>

Daniel Kersten

unread,
Nov 14, 2010, 8:27:31 AM11/14/10
to tian...@gmail.com, anic
On 13 November 2010 22:31, Tianyi Cui <tian...@gmail.com> wrote:
> The build error can be fixed using this patch from AUR:
> http://aur.archlinux.org/packages/anic-hg/anic-hg/uintptr.patch
>
> But the anic binary on my OS X 10.6 generates empty output files. It's
> like this:
>
> $ cat a.ani
> "Hello, World!" ->std.out
> $ ./anic a.ani
> $ ls -l a.out
> -rw-r--r-- 1 tianyi wheel 0 2010-11-14 06:25 a.out
>
> The size of a.out is 0. I'm not sure why. I tried build it both 32-bit
> and 64-bit and the outputs are the same.

This is expected. See my previous email.

Jeremy W. Sherman

unread,
Nov 15, 2010, 8:43:12 PM11/15/10
to anic
On Nov 12, 11:22 pm, Jon <parr...@gmail.com> wrote:
> Building main executable...
> src/types.cpp: In member function ‘TypeStatus::operator uintptr_t()
> const’:
> src/types.cpp:1514: error: cast from ‘Type*’ to ‘unsigned int’ loses
> precision
> make: *** [anic] Error 1

The function returns a `uintptr_t` by way of an `unsigned int`, which
is generally what `uintptr_t` is typedef'd to on an architecture using
32-bit pointers. 64-bit Mac OS X is an LP-64 architecture, which means
both `long` and pointers are 64-bit values. The fix for all
architectures is to change the cast from `(unsigned int)` to
`(uintptr_t)`, as in this patch:

diff --git a/src/types.cpp b/src/types.cpp
--- a/src/types.cpp
+++ b/src/types.cpp
@@ -1511,7 +1511,7 @@
TypeStatus::TypeStatus(Type *type, const TypeStatus &otherStatus) :
type(type), retType(otherStatus.retType), code(NULL) {}
TypeStatus::~TypeStatus() {}
TypeStatus::operator Type *() const {return type;}
-TypeStatus::operator uintptr_t() const {return (unsigned int)type;}
+TypeStatus::operator uintptr_t() const {return (uintptr_t)type;}
DataTree *TypeStatus::castCode(const Type &destType) const {
StdType *thisType = (StdType *)type;
StdType *otherType = (StdType *)(&destType);
Reply all
Reply to author
Forward
0 new messages