configure with clang vs gcc

I'm trying to build a native hosted mips compiler on ubuntu x86.

When I run configure with clang/llvm as the compiler, configure thinks that zlib is present and that valgrind is.

But later on the make it cannot find zlib.h. If I tell it to not do compression, then it does not look for
zlib.h but dies looking for valgrind, even if I tell it to disable-valgrind.

If I configure using gcc-mips, it decides on it's own that zlib.h is not available.
It also decides that valgrind is not available.

Why the difference?

Any ideas?

Reed

I'm trying to build a native hosted mips compiler on ubuntu x86.

When I run configure with clang/llvm as the compiler, configure thinks that
zlib is present and that valgrind is.

But later on the make it cannot find zlib.h. If I tell it to not do
compression, then it does not look for
zlib.h but dies looking for valgrind, even if I tell it to disable-valgrind.

If I configure using gcc-mips, it decides on it's own that zlib.h is not
available.
It also decides that valgrind is not available.

Why the difference?

How are you configuring?

-eric

(You can see our wiki page ) Basically:

Have you looked at the compile lines during the configure? Is it using
the system includes/libraries when building with clang rather than the
target system?

-eric

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it seems like there used to be.
You can find scripts on the internet when you google of people adding disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

Reed

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

2) The configure script should be doing this properly on it's own.
Most likely it's something like you are thinking; that it's making the decision
based on the wrong criteria; host vs. target.

#1 will allow me to work around my problem and should be there anyway.

#2 should also work but is not a requirement for me at this exact moment.
I will fix it if I can see exactly what the issue is.

Reed

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

*shrug* If you like. It's not your issue.

2) The configure script should be doing this properly on it's own.
Most likely it's something like you are thinking; that it's making the
decision
based on the wrong criteria; host vs. target.

It absolutely should not be based on any sort of triple test whatsoever.

-eric

Most likely, your gcc-mips hard codes a non-/ default sysroot, but your clang does not (it is, after all, intrinsically a cross compiler). I've successfully cross-compiled clang+llvm for MIPS before by providing a CMake toolchain file that tells it the target triple and systroot to use (along with the other flags required for my target) and it Just Works™.

Or, at least, it builds. It crashes at run time, and I've still not managed to figure out exactly why. It looks like a register value that should be preserved is not somewhere, but I have a 2GB trace that I need to look through to find out exactly where...

David

reed kotler <rkotler@mips.com> writes:

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

FWIW, because of inline asm in valgrind.h that LLVM can't yet handle, I use:

  ac_cv_header_valgrind_valgrind_h=no .../configure ...

when bootstrapping clang on z. Obviously --disable-valgrind would be
cleaner but this is another way out.

(Of course, I agree with what Eric says about it finding the wrong set
of headers.)

Thanks,
Richard

reed kotler <rkotler@mips.com> writes:

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

FWIW, because of inline asm in valgrind.h that LLVM can't yet handle, I use:

   ac_cv_header_valgrind_valgrind_h=no .../configure ...

when i do that i get:

llvm[1]: Compiling regfree.c for Release+Asserts build
llvm[1]: Compiling regstrlcpy.c for Release+Asserts build
llvm[1]: Compiling system_error.cpp for Release+Asserts build
llvm[1]: Building Release+Asserts Archive Library libLLVMSupport.a
make[1]: *** [/home/rkotler/caviumllvmwclang/build/Release+Asserts/lib/libLLVMSupport.a] Error 127
make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/lib/Support'
make: *** [all] Error 1
rkotler@mipssw006:~/caviumllvmwclang/build$

reed kotler <rkotler@mips.com> writes:

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it
seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

FWIW, because of inline asm in valgrind.h that LLVM can't yet handle, I
use:

   ac_cv_header_valgrind_valgrind_h=no .../configure ...

when i do that i get:

llvm[1]: Compiling regfree.c for Release+Asserts build
llvm[1]: Compiling regstrlcpy.c for Release+Asserts build
llvm[1]: Compiling system_error.cpp for Release+Asserts build
llvm[1]: Building Release+Asserts Archive Library libLLVMSupport.a
make[1]: ***
[/home/rkotler/caviumllvmwclang/build/Release+Asserts/lib/libLLVMSupport.a]
Error 127
make[1]: Leaving directory
`/home/rkotler/caviumllvmwclang/build/lib/Support'
make: *** [all] Error 1
rkotler@mipssw006:~/caviumllvmwclang/build$

Not enough context.

-eric

reed kotler <rkotler@mips.com> writes:

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it
seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

FWIW, because of inline asm in valgrind.h that LLVM can't yet handle, I
use:

    ac_cv_header_valgrind_valgrind_h=no .../configure ...

when i do that i get:

llvm[1]: Compiling regfree.c for Release+Asserts build
llvm[1]: Compiling regstrlcpy.c for Release+Asserts build
llvm[1]: Compiling system_error.cpp for Release+Asserts build
llvm[1]: Building Release+Asserts Archive Library libLLVMSupport.a
make[1]: ***
[/home/rkotler/caviumllvmwclang/build/Release+Asserts/lib/libLLVMSupport.a]
Error 127
make[1]: Leaving directory
`/home/rkotler/caviumllvmwclang/build/lib/Support'
make: *** [all] Error 1
rkotler@mipssw006:~/caviumllvmwclang/build$

Not enough context.

That is what it printed out.
I'm guessing that it still wanted to link in that module even though it knew no to compile it.
I will debug this and figure out why configure is getting the wrong answers with clang.

reed kotler <rkotler@mips.com> writes:

I need to leave soon and will take a look in the morning.

I did look at the autoconf input files configure.ac

There is a disable-zlib but not a disable-valgrind, even though it
seems
like there used to be.
You can find scripts on the internet when you google of people adding
disable-valgrind to configure.

I can probably implement disable-valgrind in configure.ac.

This isn't what I was asking. You can, of course, do that, but it's
orthogonal to the issue at hand. Basically my initial thought is that
it's using the contents of the build host and not the host.

-eric

Right.

There are two issues.

1 ) THere should be a way to disable valgrind as you can for zlib.

FWIW, because of inline asm in valgrind.h that LLVM can't yet handle, I
use:

    ac_cv_header_valgrind_valgrind_h=no .../configure ...

when i do that i get:

llvm[1]: Compiling regfree.c for Release+Asserts build
llvm[1]: Compiling regstrlcpy.c for Release+Asserts build
llvm[1]: Compiling system_error.cpp for Release+Asserts build
llvm[1]: Building Release+Asserts Archive Library libLLVMSupport.a
make[1]: ***

[/home/rkotler/caviumllvmwclang/build/Release+Asserts/lib/libLLVMSupport.a]
Error 127
make[1]: Leaving directory
`/home/rkotler/caviumllvmwclang/build/lib/Support'
make: *** [all] Error 1
rkotler@mipssw006:~/caviumllvmwclang/build$

Not enough context.

That is what it printed out.
I'm guessing that it still wanted to link in that module even though it knew
no to compile it.
I will debug this and figure out why configure is getting the wrong answers
with clang.

You didn't paste where an error occurred. And Richard, David, and I
have all given you your likely problem.

-eric

I see what my problem is here....

I'll continue to move further.

Seems like Richards fix is still okay.

I'm getting much further now.

The next problem is libtinfo

make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/lib/TableGen'
make[1]: Entering directory `/home/rkotler/caviumllvmwclang/build/utils'
make[2]: Entering directory `/home/rkotler/caviumllvmwclang/build/utils/FileCheck'
llvm[2]: Linking Release+Asserts executable FileCheck (without symbols)
/mips/arch/overflow/codesourcery/mips-linux-gnu/lite/release/2013.05-66/Linux/lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld: cannot find -ltinfo
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [/home/rkotler/caviumllvmwclang/build/Release+Asserts/bin/FileCheck] Error 1
make[2]: Leaving directory `/home/rkotler/caviumllvmwclang/build/utils/FileCheck'
make[1]: *** [FileCheck/.makeall] Error 2
make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/utils'
make: *** [all] Error 1
rkotler@mipssw006:~/caviumllvmwclang/build$

It's not in the gcc mips toolchain but for some reason when I configure with clang it is looking for it.

looks like i need to --disable-terminfo

i will have ot investigate in the end why configure gets the wrong answer when using clang.

David Chisnall told you the most likely answer.

-eric

Almost done....

make[2]: Entering directory `/home/rkotler/caviumllvmwclang/build/projects/sample'
/home/rkotler/caviumllvmwclang/build/projects/sample/Makefile.llvm.config:50: *** Projects must define PROJ_INSTALL_ROOT. Stop.
make[2]: Leaving directory `/home/rkotler/caviumllvmwclang/build/projects/sample'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/projects'

I don't know why configure is making so many mistakes here but i will examine that later.
It used to work for us.

COmplete build now successful.

Yay!

I will try and figure out what is wrong with configure as a background task.

But I have a way to build the mips hosted version using clang/llvm instead of gcc.

Now to debug this compiler.

Reed