On 8 Nov 2011, at 12:29, Quentin Mathé wrote: > Le 7 nov. 2011 à 13:46, David Chisnall a écrit : > >> On 7 Nov 2011, at 12:04, Quentin Mathé wrote: >> >>> Hi, >>> >>> To compile LanguageKit, I had to work around the glibc __block issue in >>> various places once again. >>> The patch is pretty ugly, so before committing it I wanted to know if >>> someone had a better solution. >> >> The same better solution I've suggested the last four times you've >> encountered this problem: >> >> $ cat unistd.h >> #ifdef __block >> # undef __block >> # include_next "unistd.h" >> # define __block __attribute__((__blocks__(byref))) >> #else >> # include_next "unistd.h" >> #endif >> >> Just drop this file into any directory that has problem (or install it in >> Local/Library/Headers) and never think about it again. > > I read about this solution in a recent mail you sent about ObjectMerging, but > I thought it wouldn't work in this case since the include directives to > override are in the LLVM code. > But it does work. That's neat. > >>> I tested various examples from the Compiler/Examples directory, and they >>> run fine. However test.st doesn't work, I get: >>> >>> edlc -f test.st >>> 2011-11-07 13:00:59.907 edlc[9986] ERROR: Can not determine type for sqrt >>> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim >>> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim >>> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar >>> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar >>> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar >>> 2011-11-07 13:00:59.911 edlc[9986] Failed to compile input. >> >> If you don't have SourceCodeKit installed, this test won't work. > > After some trials and errors, I got this working by moving libobjc2/opts to > lib/Transforms in my LLVM working copy, and compiling it.
There is a script for doing this for you. It shouldn't be needed to build SCK though, unless I accidentally committed some testing compile flags. > However I had to put ~/reps/llvm3/Release+Debug+Asserts/lib in my > LD_LIBRARY_PATH, because editing the -load path passed through the CFLAGS in > the SourceCodeKit GNUmakefile had no effects. In this case, edlc was > complaining about being unable to find libclang.so. Ah, I did. The simplest thing to do is just remove them. They add some extra optimisations, but in 99.9% of the time they're not really worth bothering with. I'll make clang run them by magic eventually. > So test.st now run fine :-) > > May be we should include SourceCodeKit in the build process now ? Or tweak > test.st to call C functions only if SourceCodeKit has been loaded. There isn't really any way of doing this, unfortunately. I've never really cared about making test.st work everywhere, because it's just my place for adding ad-hoc tests, not part of the proper test suite. > Yes, I'm using LanguageKit from yesterday. > With the JIT, the test runs fine in fact. > > With the interpreter, the loops that exercise the negative arithmetic never > end. Not sure why that is. I'll take a look and see. The interpreter probably need a bit of work before the release. David -- Sent from my Cray X1 _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
