1.7 Pre-Release Ready for Testing

Project Infrastructure LLVM Dev List Archives
1

I've put the pre-release tar balls here:
http://llvm.org/prereleases/1.7/

I'm asking for help to test this release and to review documentation. If anyone can spare some time to help out, I would really appreciate it. The more people that test, the better this release will be.

Secondly, now that the tarballs have been created, everyone is free to check in documentation changes into the the release branch (and cvs main too). For code changes, please check them into mainline CVS, then email me to let
me know that they should be pulled into the release.

For testing, we would like a mix of people to do x86 and ppc. Please send email to the list if you plan to test, what architecture, and if you will use the llvm-gcc binary or compile it yourself. That way, I know who to expect results from.

Here are some basic guidelines.

1) Build and install llvmgcc, or use the binary.
2) Build llvm. It would be great if some could do objdir != srcdir and vice versa. You could also try doing a make install.
3) Once everything is ready, run make check (report results)
4) Lastly, run the tests in llvm-test. Report results.

I know this may be a bit rushed, but if the testing and documentation review could be completed by April 18th, that would be great. Please either commit updates to the documentation, or mail patches to the llvmbugs list. Future releases will be more organized and provide more time for testing. I know everyone has busy schedules, so I appreciate all the help.

Thanks,
Tanya

2

Hi I am doing work on a powerPC based Openbsd 3.8 system iBookg4 and on OpenBSD 3.8 i386. Are these supported in the build system yet. I got 1.6 to build but the gcc-llvm was a no go in configure except by gentle hand building each section and figuring out what it wanted as I went…
I notice Support for OpenBSD 2.8 which is quite dated… I am using pro-Police compiler GCC 3.3 but would like to use some of the benifits of llvm on the MacPPC’s/i386 on a more modern version of Canadian OpenBSD 3.8 or 3.9 is good too. WHat can I do? Who build your current config script can I talk with them?

Where is llvmgcc built from?? I am only interested in C builds, I do not need C++ or java or others.

thanks so much for any pointers or help. :slight_smile: regards, IVO(josephAltea)

3

I will test on Darwin/PPC, I'll try the precompiled llvmgcc, objdir != srcdir.

-Chris

4

Hi Tanya,

Attached are the "make check" results from my machine Darwin
Bill-Wendlings-Computer.local 8.6.0 Darwin Kernel Version 8.6.0: Tue
Mar 7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power
Macintosh powerpc

I'll have the llvm-test results available later.

-bw

check.out (6.39 KB)

5

I would like to test but the I modigied the configure
to make unknown = OpenBSD and Unix and go pretty far but
it died right after ‘supports mkdir’ yes…
then the next line was ‘your system is unsupported’’
I have gcc 3.3 on OpenBSD 3.3 pro-police stack compiler…
I am only really interested in testing the C/C++ but C primarily
for my work.
regards, Joseph Altea

6

Are us on Mac OSX or GNU Darwin without apple OS…
I am trying to get it going on OpenBSD 3.8/3.9 latest but
seems that the compiler boffs on this system… Should I send
the configure output-- could anybody maybe have a hint about why
its blowing up…?
regards, Joseph Altea

7

To my knowledge noone has tried to get LLVM to work on OpenBSD yet. I'm sorry it doesn't work for you out of the box, but if you'd like to investigate and contribute patches to make it work, we would be happy to apply them to mainline CVS. LLVM 1.7 is not going to take patches to add new supported platforms.

-Chris

8

Hi Josephm

I would like to test but the I modigied the configure to make unknown
= OpenBSD and Unix and go pretty far but it died right after 'supports
mkdir' yes...

Could that have been `checking for mkdir...'?

then the next line was 'your system is unsupported''

Have you looked at ./config.log. ./configure creates this as it runs as
a trace of the path it took through ./configure. Work backwards from
the end to find out what it didn't like.

Cheers,

Ralph.

PS. Could you quote text you're replying to as otherwise it can make
reading the email a little confusing.

9

Hi again,

I wrote:

> I would like to test but the I modigied the configure to make
> unknown = OpenBSD and Unix

Have you looked at ./config.log. ./configure creates this as it runs
as a trace of the path it took through ./configure. Work backwards
from the end to find out what it didn't like.

I remember SourceForge's compile farm has an OpenBSD x86 machine so
thought I'd give it a go with a recent CVS check-out.

    $ ./configure
    configure: WARNING: Unknown project (HowToUseJIT) won't be configured automatically
    configure: WARNING: Unknown project (ModuleMaker) won't be configured automatically
    configure: WARNING: Unknown project (SmallExamples) won't be configured automatically
    checking build system type... i386-unknown-openbsd3.8
    checking host system type... i386-unknown-openbsd3.8
    checking target system type... i386-unknown-openbsd3.8
    checking type of operating system we're on... Unknown
    configure: error: Operating system is unknown, configure can't continue

LLVM's configure.ac has a hard-coded list of supported platforms, which
is a shame, and `openbsd' isn't in it.

    [case $build in
      *-*-aix*)
        llvm_cv_os_type="AIX"
        llvm_cv_platform_type="Unix" ;;
    ...
      *-*-freebsd*)
        llvm_cv_os_type="FreeBSD"
        llvm_cv_platform_type="Unix" ;;

So I forged `freebsd'

    $ ./configure --build=i386-unknown-freebsd3.8

and ./configure completed successfully. gmake stopped with

    llvm[1]: Compiling Mutex.cpp for Debug build
    Mutex.cpp:55: warning: the address of `int pthread_mutex_init(volatile
       pthread_mutex**, pthread_mutex_attr* const*)', will always be `true'
    Mutex.cpp: In constructor `llvm::sys::Mutex::Mutex(bool)':
    Mutex.cpp:80: error: `pthread_mutexattr_setpshared' undeclared (first use this
       function)
    Mutex.cpp:80: error: (Each undeclared identifier is reported only once for each
       function it appears in.)

    78 #ifndef __FreeBSD__
    79 // Make it a process local mutex
    80 errorcode = pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_PRIVATE);
    81 #endif

So I modified both occurrences of __FreeBSD__ to also check for
__OpenBSD__.

The next problem was INT8_MAX, etc., weren't being defined.
include/llvm/Support/DataTypes.h.in is inadequate for this platform. I
dumped a set of definitions into each file that wanted them as a bodge.
Better autoconf tests could set up INT8_MAX, etc., on all platforms that
don't define them.

After that, the build completed and I could run llvm-{as,dis} and lli.

So with a little work, OpenBSD looks like it could be supported out of
the box. I've only a low-bandwidth Internet connection at the moment so
it won't be by me but is there a `how to submit a patch for LLVM'
document somewhere?

Cheers,

Ralph.

10

I just added __OpenBSD__ everywhere __FreeBSD__ was being tested (there were about a dozen places). I suspect we'll have to add one for NetBSD also one day (even DragonflyBSD?). INT8_MAX and friends ought to be declared by <stdint.h>. It is on FreeBSD.

Ralph Corderoy wrote:

11

I’ll Check it out… is it in the CVS or the release yet… or how do I apply a patch to it… thanks much for the update… I’ll feel better about the whole thing…OpenBSD is really nice with the pro-police stack and would like to see an alternative to the GCC only compiler chain of tools especially as it is based on a somewhat archaic optiminzation backend and procedural stuff is pretty dated in the RTL layer… Aho and Ullman can only take you so far…
Then you need to use the FORCE… LUKE use the force… of llvm that is.
:slight_smile: cheers all.

12

CVS. I doubt it will be pulled into the imminent 1.7 release. I didn't make any configure changes; Reid will have to do that.

Joseph Altea wrote:

13

Hi Jeff,

I just added __OpenBSD__ everywhere __FreeBSD__ was being tested
(there were about a dozen places). I suspect we'll have to add one
for NetBSD also one day (even DragonflyBSD?).

Thanks. Although it would be better to come up with a autoconf test for
the feature than keep maintaining the #ifdefs, etc.

INT8_MAX and friends ought to be declared by <stdint.h>. It is on
FreeBSD.

That file doesn't exist on this OpenBSD 3.8 installation. And that
symbol doesn't exist under /usr/include. I guess it's not uncommon
given things like
http://autoconf-archive.cryp.to/ax_create_stdint_h.html

Cheers,

Ralph.

14

I’ll test on Darwin/PPC, precompiled llvmgcc, objdir == srcdir.

Rob

15

The build failed on i686-pc-linux-gnu.

llvm[2]: Flexing FileLexer.l
llvm[2]: Compiling FileLexer.cpp for Release build
/home/rogelio/Desktop/llvm/utils/TableGen/FileLexer.l: In function
'int Filelex()':
/home/rogelio/Desktop/llvm/utils/TableGen/FileLexer.l:205: error:
'STRCONCATTOK' was not declared in this scope
Lexer.cpp: In function 'int yy_get_next_buffer()':
Lexer.cpp:1369: warning: comparison between signed and unsigned
integer expressions
make[2]: *** [/home/rogelio/Desktop/llvm/utils/TableGen/Release/FileLexer.o]
Error 1
make[2]: Leaving directory `/home/rogelio/Desktop/llvm/utils/TableGen'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/rogelio/Desktop/llvm/utils'
make: *** [all] Error 1

any suggestions how to debug this?

Krgds,
Roger

16

Ialready figured it out. I ran the build in the source dir.

17

I haven’t seen anyone claim x86 linux objdir == srcdir, so I’ll test it out. Missed the 18th,but I’ll try to have it done asap.

18

Sorry for being ambiguous.

x86 builds only if srcdir != objdir. otherwise you get the error i had earlier.

19

I already successfully built with srcdir == objdir. I assumed you meant that
you did srcdir != objdir and accidently typed make in your srcdir (or something
I'm not really up to speed on the whole objdir != srcdir thing because I've always
been dirty and built in my src directories).

20

I have flex version 2.5.31, gcc version 3.3.5 (Debian 1:3.3.5-13), and am obviously using Debian.
I would assume that the reason your build fails and mine succeeds in due to one (or more) of those
things being different :wink: