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. 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. 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. >> I also ran the test suite. Various Smalltalk tests related to the >> interpreter fail, but the JIT tests pass in most cases except: > > There are a few bugs in the interpreter. Most of the core stuff works, but > it needs a bit of work before the release. ok >> - TestTimesRepeat (removed from the output below, because it never ends) > > I could reproduce this, but then I updated LanguageKit and it was gone. Are > you using LK trunk? 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. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
