problems compiling hello.pure
EdK
When I try to compile a simple hello world program I get:
new-host:pure edkeith$ pure -c hello.pure
opt: a.out.bc: Invalid MODULE_CODE_GLOBALVAR record
Undefined symbols:
"___pure_main__", referenced from:
_main in pure_main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
hello.pure is
#! /usr/local/bin/pure -x
using system;
main = puts "hello, world!";
// no need to run the program at compile time
if compiling then () else main;
I know I was able to compile it on May 10 2011.
I am using mac ports. It has probably been updated since I last
compiled pure code to an executable.
I am having no problems with the 'interpereter'.
Can anyone give me any advice?
Thank you,
-EdK
Albert Graef
> I'm having problems compliling pure progams on Mac OS X Snow Leppard.
>
> When I try to compile a simple hello world program I get:
>
> new-host:pure edkeith$ pure -c hello.pure
> opt: a.out.bc: Invalid MODULE_CODE_GLOBALVAR record
> Undefined symbols:
> "___pure_main__", referenced from:
> _main in pure_main.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
Looks like an LLVM bug. Which LLVM version is that? ('pure --version'
should print it. Also, please check what 'opt --version' reports, it
should match.) Also, can you please post the LLVM assembler code for the
module, so that I can check it? You can obtain the assembler source
with: pure -c hello.pure -o hello.ll
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Ed Keith
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.9
Optimized build.
Built Apr 10 2011 (22:51:05).
Host: x86_64-apple-darwin10
Host CPU: i686
Registered Targets:
(none)
new-host:pure edkeith$ pure --version
Pure 0.51 (x86_64-apple-darwin10.8.0) Copyright (c) 2008-2011 by Albert Graef
Compiled for LLVM 3.0 (http://llvm.org)
From: Albert Graef <Dr.G...@t-online.de>
To: pure...@googlegroups.com
Sent: Monday, February 13, 2012 3:51 PM
Subject: Re: [pure-lang] problems compiling hello.pure
-- You received this message because you are subscribed to the Google Groups "pure-lang" group.
To post to this group, send email to pure...@googlegroups.com.
To unsubscribe from this group, send email to pure-lang+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pure-lang?hl=en.
Ryan Schmidt
On Feb 13, 2012, at 13:45, EdK wrote:
> I'm having problems compliling pure progams on Mac OS X Snow Leppard.
>
> When I try to compile a simple hello world program I get:
>
> new-host:pure edkeith$ pure -c hello.pure
> opt: a.out.bc: Invalid MODULE_CODE_GLOBALVAR record
> Undefined symbols:
> "___pure_main__", referenced from:
> _main in pure_main.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
> hello.pure is
>
> #! /usr/local/bin/pure -x
>
> using system;
>
> main = puts "hello, world!";
>
> // no need to run the program at compile time
> if compiling then () else main;
>
> I know I was able to compile it on May 10 2011.
>
> I am using mac ports.
[snip]
Just to clarify: are you using MacPorts to install pure or compiling it manually? MacPorts' default prefix is /opt/local but your shebang line says /usr/local/bin/pure.
Albert Graef
> Thanks for getting back to me. Here is the information you asked for. It
> looks like I have two different versions of LLVM installed.
Yes, indeed. Apparently you built Pure against LLVM 3.0, but you have
the command line utilities from LLVM 2.9 installed. That won't work,
since the LLVM 2.9 tools will not handle LLVM 3.0 bitcode correctly.
> The assmbler source is attached.
The assembler file looks good. It also compiles and runs fine on my
Linux system. So the LLVM toolchain on your system must be the cuplrit.
I suggest that you completely get rid of the LLVM 2.9 installation and
make sure that you have the proper toolchain from LLVM 3.0 installed.
Maybe something went wrong when you last upgraded your MacPorts? Sorry,
I don't have a Mac, so I can't help you with that. But maybe other Mac
users on this list can chime in and give you a helping hand.
Ed Keith
Sent: Monday, February 13, 2012 5:00 PM
Subject: Re: [pure-lang] problems compiling hello.pure
Ryan Schmidt
On Feb 14, 2012, at 07:48, Ed Keith wrote:
> It looks like I had two incompatable versions of llvm. One was from mac ports, and I think the other was from xcode. Since I did not want to breal xcode I uninstalled the mac ports versions of pure and llvm and build pure from source. Now everything seems to work.
Since MacPorts requires Xcode, that would imply that pure in MacPorts, which always uses llvm in MacPorts, never works; I can't believe that's the case; I would assume I would have received bug reports.
For some history: the pure port in MacPorts used to use the llvm port, which was llvm version 2.9. The llvm port was then deprecated and replaced with the ports llvm-2.9, llvm-3.0 and llvm-3.1 (prerelease), with the intention that all three could be installed simultaneously and coexist peacefully; the pure port in MacPorts was then changed to use the llvm-3.0 port.
Albert Graef
On 02/14/2012 06:52 PM, Ryan Schmidt wrote:
> On Feb 14, 2012, at 07:48, Ed Keith wrote:
>> It looks like I had two incompatable versions of llvm. One was from mac ports, and I think the other was from xcode. Since I did not want to breal xcode I uninstalled the mac ports versions of pure and llvm and build pure from source. Now everything seems to work.
>
> Since MacPorts requires Xcode, that would imply that pure in MacPorts, which always uses llvm in MacPorts, never works; I can't believe that's the case; I would assume I would have received bug reports.
Well, the issue only became apparent when using the batch compiler (pure
-c). This in turn invokes the LLVM utilities llc and opt, and the
utilities that Ed had on his PATH happened to be the ones from LLVM 2.9,
not LLVM 3.0 which Pure was built against.
If you only run Pure in interpreter mode, you'll never notice this kind
of mismatch, since the LLVM toolchain (llc, opt) is never invoked.
> For some history: the pure port in MacPorts used to use the llvm port, which was llvm version 2.9. The llvm port was then deprecated and replaced with the ports llvm-2.9, llvm-3.0 and llvm-3.1 (prerelease), with the intention that all three could be installed simultaneously and coexist peacefully; the pure port in MacPorts was then changed to use the llvm-3.0 port.
The question is, where do the LLVM utilities end up if you have
different LLVM versions installed? As far as I can tell from the
portfiles, they're installed with different version suffixes, is that right?
In that case Pure's batch compiler (interpreter::compiler() in
interpreter.cc) will have to be patched up so that it invokes the proper
binaries for the LLVM version that it is linked against. I could maybe
add some --with options to configure to make that possible without
patching the source code.
Ryan Schmidt
> On 02/14/2012 06:52 PM, Ryan Schmidt wrote:
>> For some history: the pure port in MacPorts used to use the llvm port, which was llvm version 2.9. The llvm port was then deprecated and replaced with the ports llvm-2.9, llvm-3.0 and llvm-3.1 (prerelease), with the intention that all three could be installed simultaneously and coexist peacefully; the pure port in MacPorts was then changed to use the llvm-3.0 port.
>
> The question is, where do the LLVM utilities end up if you have different LLVM versions installed? As far as I can tell from the portfiles, they're installed with different version suffixes, is that right?
Yes:
$ port contents llvm-2.9 | grep /bin/
/opt/local/bin/bugpoint-mp-2.9
/opt/local/bin/llc-mp-2.9
/opt/local/bin/lli-mp-2.9
/opt/local/bin/llvm-ar-mp-2.9
/opt/local/bin/llvm-as-mp-2.9
/opt/local/bin/llvm-bcanalyzer-mp-2.9
/opt/local/bin/llvm-config-mp-2.9
/opt/local/bin/llvm-diff-mp-2.9
/opt/local/bin/llvm-dis-mp-2.9
/opt/local/bin/llvm-extract-mp-2.9
/opt/local/bin/llvm-ld-mp-2.9
/opt/local/bin/llvm-link-mp-2.9
/opt/local/bin/llvm-mc-mp-2.9
/opt/local/bin/llvm-nm-mp-2.9
/opt/local/bin/llvm-objdump-mp-2.9
/opt/local/bin/llvm-prof-mp-2.9
/opt/local/bin/llvm-ranlib-mp-2.9
/opt/local/bin/llvm-stub-mp-2.9
/opt/local/bin/llvmc-mp-2.9
/opt/local/bin/macho-dump-mp-2.9
/opt/local/bin/opt-mp-2.9
/opt/local/bin/tblgen-mp-2.9
/opt/local/libexec/llvm-2.9/bin/bugpoint
/opt/local/libexec/llvm-2.9/bin/llc
/opt/local/libexec/llvm-2.9/bin/lli
/opt/local/libexec/llvm-2.9/bin/llvm-ar
/opt/local/libexec/llvm-2.9/bin/llvm-as
/opt/local/libexec/llvm-2.9/bin/llvm-bcanalyzer
/opt/local/libexec/llvm-2.9/bin/llvm-config
/opt/local/libexec/llvm-2.9/bin/llvm-diff
/opt/local/libexec/llvm-2.9/bin/llvm-dis
/opt/local/libexec/llvm-2.9/bin/llvm-extract
/opt/local/libexec/llvm-2.9/bin/llvm-ld
/opt/local/libexec/llvm-2.9/bin/llvm-link
/opt/local/libexec/llvm-2.9/bin/llvm-mc
/opt/local/libexec/llvm-2.9/bin/llvm-nm
/opt/local/libexec/llvm-2.9/bin/llvm-objdump
/opt/local/libexec/llvm-2.9/bin/llvm-prof
/opt/local/libexec/llvm-2.9/bin/llvm-ranlib
/opt/local/libexec/llvm-2.9/bin/llvm-stub
/opt/local/libexec/llvm-2.9/bin/llvmc
/opt/local/libexec/llvm-2.9/bin/macho-dump
/opt/local/libexec/llvm-2.9/bin/opt
/opt/local/libexec/llvm-2.9/bin/tblgen
$ port contents llvm-3.0 | grep /bin/
/opt/local/bin/bugpoint-mp-3.0
/opt/local/bin/llc-mp-3.0
/opt/local/bin/lli-mp-3.0
/opt/local/bin/llvm-ar-mp-3.0
/opt/local/bin/llvm-as-mp-3.0
/opt/local/bin/llvm-bcanalyzer-mp-3.0
/opt/local/bin/llvm-config-mp-3.0
/opt/local/bin/llvm-cov-mp-3.0
/opt/local/bin/llvm-diff-mp-3.0
/opt/local/bin/llvm-dis-mp-3.0
/opt/local/bin/llvm-dwarfdump-mp-3.0
/opt/local/bin/llvm-extract-mp-3.0
/opt/local/bin/llvm-ld-mp-3.0
/opt/local/bin/llvm-link-mp-3.0
/opt/local/bin/llvm-mc-mp-3.0
/opt/local/bin/llvm-nm-mp-3.0
/opt/local/bin/llvm-objdump-mp-3.0
/opt/local/bin/llvm-prof-mp-3.0
/opt/local/bin/llvm-ranlib-mp-3.0
/opt/local/bin/llvm-rtdyld-mp-3.0
/opt/local/bin/llvm-size-mp-3.0
/opt/local/bin/llvm-stub-mp-3.0
/opt/local/bin/llvm-tblgen-mp-3.0
/opt/local/bin/macho-dump-mp-3.0
/opt/local/bin/opt-mp-3.0
/opt/local/libexec/llvm-3.0/bin/bugpoint
/opt/local/libexec/llvm-3.0/bin/llc
/opt/local/libexec/llvm-3.0/bin/lli
/opt/local/libexec/llvm-3.0/bin/llvm-ar
/opt/local/libexec/llvm-3.0/bin/llvm-as
/opt/local/libexec/llvm-3.0/bin/llvm-bcanalyzer
/opt/local/libexec/llvm-3.0/bin/llvm-config
/opt/local/libexec/llvm-3.0/bin/llvm-cov
/opt/local/libexec/llvm-3.0/bin/llvm-diff
/opt/local/libexec/llvm-3.0/bin/llvm-dis
/opt/local/libexec/llvm-3.0/bin/llvm-dwarfdump
/opt/local/libexec/llvm-3.0/bin/llvm-extract
/opt/local/libexec/llvm-3.0/bin/llvm-ld
/opt/local/libexec/llvm-3.0/bin/llvm-link
/opt/local/libexec/llvm-3.0/bin/llvm-mc
/opt/local/libexec/llvm-3.0/bin/llvm-nm
/opt/local/libexec/llvm-3.0/bin/llvm-objdump
/opt/local/libexec/llvm-3.0/bin/llvm-prof
/opt/local/libexec/llvm-3.0/bin/llvm-ranlib
/opt/local/libexec/llvm-3.0/bin/llvm-rtdyld
/opt/local/libexec/llvm-3.0/bin/llvm-size
/opt/local/libexec/llvm-3.0/bin/llvm-stub
/opt/local/libexec/llvm-3.0/bin/llvm-tblgen
/opt/local/libexec/llvm-3.0/bin/macho-dump
/opt/local/libexec/llvm-3.0/bin/opt
$
Albert Graef
> On Feb 14, 2012, at 13:12, Albert Graef wrote:
>> The question is, where do the LLVM utilities end up if you have different LLVM versions installed? As far as I can tell from the portfiles, they're installed with different version suffixes, is that right?
>
> Yes:
Ok, so that means the Pure's batch compiler will be broken unless the
user points PATH to the proper /opt/local/libexec/llvm-*/bin directory.
I would assume that other LLVM applications which rely on the LLVM
toolchain will be affected by this change as well.
Ryan, do you have any suggestion how we should resolve this issue? What
does the maintainer of the LLVM port say about this?
Ryan Schmidt
On Feb 15, 2012, at 17:33, Albert Graef wrote:
> On 02/14/2012 10:06 PM, Ryan Schmidt wrote:
>> On Feb 14, 2012, at 13:12, Albert Graef wrote:
>>> The question is, where do the LLVM utilities end up if you have different LLVM versions installed? As far as I can tell from the portfiles, they're installed with different version suffixes, is that right?
>>
>> Yes:
>
> Ok, so that means the Pure's batch compiler will be broken unless the user points PATH to the proper /opt/local/libexec/llvm-*/bin directory. I would assume that other LLVM applications which rely on the LLVM toolchain will be affected by this change as well.
>
> Ryan, do you have any suggestion how we should resolve this issue?
If I patch pure's interpreter.cc in MacPorts to refer to opt and llc by their full names as they're installed by the llvm-3.0 port, then instead of getting a message that opt and llc cannot be found, I get thousands of errors like this:
a.out.s:5:Unknown pseudo-op: .cfi_startproc
a.out.s:9:Unknown pseudo-op: .cfi_def_cfa_offset
a.out.s:9:Rest of line ignored. 1st junk character valued 49 (1).
According to this...
http://old.nabble.com/llvm-3.0-svn-and-cfi_*-directives-td32169409.html
...since my compiler is gcc and not clang, I need to pass -disable-cfi to llc. When I additionally do that, then it works. (Hopefully it will also work for those MacPorts users whose compiler is clang.)
https://trac.macports.org/changeset/90576
Albert Graef
On 03/09/2012 07:36 AM, Ryan Schmidt wrote:
> According to this...
>
> http://old.nabble.com/llvm-3.0-svn-and-cfi_*-directives-td32169409.html
>
> ...since my compiler is gcc and not clang, I need to pass -disable-cfi to llc. When I additionally do that, then it works. (Hopefully it will also work for those MacPorts users whose compiler is clang.)
>
> https://trac.macports.org/changeset/90576
Hmm, this seems to be a new issue with LLVM 3.0 on OSX. Thanks for
investigating this, I'll see whether I can add something equivalent to
your changeset to my sources asap.
Albert Graef
> On 03/09/2012 07:36 AM, Ryan Schmidt wrote:
>> According to this...
>>
>> http://old.nabble.com/llvm-3.0-svn-and-cfi_*-directives-td32169409.html
>>
>> ...since my compiler is gcc and not clang, I need to pass -disable-cfi
>> to llc. When I additionally do that, then it works. (Hopefully it will
>> also work for those MacPorts users whose compiler is clang.)
>>
>> https://trac.macports.org/changeset/90576
>
> Hmm, this seems to be a new issue with LLVM 3.0 on OSX. Thanks for
> investigating this, I'll see whether I can add something equivalent to
> your changeset to my sources asap.
I added the -disable-cfi option in rev. b33abde6b6b9. It's only enabled
for OSX and LLVM 3.0 for now, though.
Note that you'll still have to patch the source for the tool names. As
the mangling of the LLVM tool names is a MacPorts-specific thing,
generally adding this for OSX compilation would break things for users
who install LLVM from the official sources.
Ryan Schmidt
On Mar 17, 2012, at 18:49, Albert Graef wrote:
> I added the -disable-cfi option in rev. b33abde6b6b9. It's only enabled for OSX and LLVM 3.0 for now, though.
Thanks.
> Note that you'll still have to patch the source for the tool names. As the mangling of the LLVM tool names is a MacPorts-specific thing, generally adding this for OSX compilation would break things for users who install LLVM from the official sources.
Might it be appropriate to have a configure option to specify the tool names? Since it's possible to build llvm with nonstandard tool names, or with the tools installed to nonstandard locations, it seems like it would make sense to let me tell pure's configure script that I've done that, rather than having to patch some sourcefile.
But if you don't want to, I'm happy to continue patching the file in MacPorts; it's not a big deal.
Albert Graef
sorry for replying so late, somehow your post escaped my attention.
On 03/26/2012 11:52 AM, Ryan Schmidt wrote:
> Might it be appropriate to have a configure option to specify the tool names? Since it's possible to build llvm with nonstandard tool names, or with the tools installed to nonstandard locations, it seems like it would make sense to let me tell pure's configure script that I've done that, rather than having to patch some sourcefile.
Well, I don't really like the idea of a configure option. That will
break things much too easily if the user upgrades his LLVM installation.
Also note that LLVM does *not* offer an "official" option to build with
nonstandard tool names, at least I don't see any in the LLVM docs. This
is a speciality of the MacPorts port. So at least right now it seems
reasonable to assume that some working default set of LLVM tools is
available on the standard PATH, and this is what Pure does.
Therefore my take is that the problem should be fixed in MacPorts, not
in Pure. I think that at least the MacPorts port of LLVM should come
with a dire warning that users need to set up their environment to make
the LLVM toolchain work as advertized. Or maybe MacPorts should try to
push some kind of option to build with nonstandard tool names upstream.
As soon as there's an "officially sanctioned" way to have different LLVM
versions installed on the same system, I'll be happy to support that as
best as I can.
Cheers,
Ryan Schmidt
On Apr 3, 2012, at 12:09, Albert Graef wrote:
> On 03/26/2012 11:52 AM, Ryan Schmidt wrote:
>> Might it be appropriate to have a configure option to specify the tool names? Since it's possible to build llvm with nonstandard tool names, or with the tools installed to nonstandard locations, it seems like it would make sense to let me tell pure's configure script that I've done that, rather than having to patch some sourcefile.
>
> Well, I don't really like the idea of a configure option. That will break things much too easily if the user upgrades his LLVM installation.
>
> Also note that LLVM does *not* offer an "official" option to build with nonstandard tool names, at least I don't see any in the LLVM docs. This is a speciality of the MacPorts port. So at least right now it seems reasonable to assume that some working default set of LLVM tools is available on the standard PATH, and this is what Pure does.
>
> Therefore my take is that the problem should be fixed in MacPorts, not in Pure. I think that at least the MacPorts port of LLVM should come with a dire warning that users need to set up their environment to make the LLVM toolchain work as advertized. Or maybe MacPorts should try to push some kind of option to build with nonstandard tool names upstream. As soon as there's an "officially sanctioned" way to have different LLVM versions installed on the same system, I'll be happy to support that as best as I can.
It's already fixed in MacPorts version of pure, so there's no problem really.
You're right that the symlinks like llc-mp-3.0 and opt-mp-3.0 that we create in ${prefix}/bin are nonstandard, so ignore that part of what I said above.
However, llvm does have the standard --prefix configure option, and that's what we use to put each version of llvm in its own directory ${prefix}/libexec/llvm-${version}. But users aren't expected to necessarily have that in their PATH. So in MacPorts I'm patching pure to call llc and opt by their absolute paths in that directory.
Albert Graef
> It's already fixed in MacPorts version of pure, so there's no problem really.
Ok, fine, then we can just leave it at that for now. :)
Albert Graef
of different LLVM versions out there this definitely makes life easier
for package maintainers.
As of rev. 7d58960d04c6, there's now a --with-tool-prefix configure
option which can be used to specify the path under which the LLVM
toolchain is installed. So on the Mac something like './configure
--with-tool-prefix=/opt/local/libexec/llvm-3.0/bin' should now do the trick.
Albert Graef
> As of rev. 7d58960d04c6, there's now a --with-tool-prefix configure
> option which can be used to specify the path under which the LLVM
> toolchain is installed. So on the Mac something like './configure
> --with-tool-prefix=/opt/local/libexec/llvm-3.0/bin' should now do the trick.
llvm-config-<version> with the newest version if llvm-config isn't
available.
Lucas Paul
> On 06/03/2012 02:23 AM, Albert Graef wrote:
>> As of rev. 7d58960d04c6, there's now a --with-tool-prefix configure
>> option which can be used to specify the path under which the LLVM
>> toolchain is installed. So on the Mac something like './configure
>> --with-tool-prefix=/opt/local/libexec/llvm-3.0/bin' should now do the trick.
- Lucas
Albert Graef
> On 06/03/2012 02:23 AM, Albert Graef wrote:
>> > As of rev. 7d58960d04c6, there's now a --with-tool-prefix configure
>> > option which can be used to specify the path under which the LLVM
>> > toolchain is installed. So on the Mac something like './configure
>> > --with-tool-prefix=/opt/local/libexec/llvm-3.0/bin' should now do the trick.
> Oh, and the configure script now also checks for an
> llvm-config-<version> with the newest version if llvm-config isn't
> available.
http://docs.pure-lang.googlecode.com/hg/install.html#tool-prefix-and-llvm-version.
I guess that this should cover all possible cases. configure will try to
find a suitable llvm-config as best as it can, but will take into
account the specified --with-tool-prefix and --with-llvm-version options
first. It should also be able to deal with both local LLVM installations
from the official sources and versioned installs from ports or binary
packages.
Ryan, what this means for you is that starting with Pure 0.55 you should
be able to just add
'--with-tool-prefix=/opt/local/libexec/llvm-<version>/bin' to the
configure stage of your port and everything should just work, no source
patches needed. Are you happy with that or do you need anything else?
Albert
Ryan Schmidt
On Jun 4, 2012, at 03:44, Albert Graef wrote:
> Ryan, what this means for you is that starting with Pure 0.55 you should
> be able to just add
> '--with-tool-prefix=/opt/local/libexec/llvm-<version>/bin' to the
> configure stage of your port and everything should just work, no source
> patches needed. Are you happy with that or do you need anything else?
Is pure 0.55 a good time for us to switch from llvm 3.0 to 3.1?
Do I need to rebuild all the pure modules with 0.55 and/or if I switch the version of llvm used, or should the old modules continue to work?
Albert Graef
> Is pure 0.55 a good time for us to switch from llvm 3.0 to 3.1?
it for quite some time over here and didn't notice any problems.
> Do I need to rebuild all the pure modules with 0.55 and/or if I switch the version of llvm used, or should the old modules continue to work?
switch to LLVM 3.1. The runtime API hasn't changed (still at libpure8).
So only the Pure package needs to be rebuilt.
(That's one nice thing about me putting on the hat of a package
maintainer for my recent Launchpad activities: I got to review the
dependencies between the different packages pretty thoroughly. So I can
say with some confidence that the only part of the Pure core which
really depends on LLVM is the libpure runtime library.)