[LLVMdev] Compiling llvm and Clang in solaris 10

[Jorge Rodrigues]

 

I run configure in a build folder using

 

CC=gcc CXX=g++  ../configure --prefix=/project/scratch/packages2/clang  \
  --enable-targets=host --enable-shared

 

The configure runs fine but when I type make I get the error:

 

make[1]: Entering directory `/project/scratch/tmp/llvm-3.3/build/lib/Support'
llvm[1]: Compiling APFloat.cpp for Release+Asserts build
In file included from /project/scratch/tmp/llvm-3.3/include/llvm/ADT/Hashing.h:50:0,
                 from /project/scratch/tmp/llvm-3.3/lib/Support/APFloat.cpp:18:
/project/scratch/tmp/llvm-3.3/include/llvm/Support/Host.h:23:28: fatal error: machine/endian.h: No such file or directory
 #include <machine/endian.h>
                            ^
compilation terminated.
/project/packages/sun/5.10/x86/gnu/bin/rm: cannot remove `/project/scratch/tmp/llvm-3.3/build/lib/Support/Release+Asserts/APFloat.d.tmp': No such file or directory
make[1]: *** [/project/scratch/tmp/llvm-3.3/build/lib/Support/Release+Asserts/APFloat.o] Error 1
make[1]: Leaving directory `/project/scratch/tmp/llvm-3.3/build/lib/Support'
make: *** [all] Error 1

 

Any idea how I can solve this? Thanks.

[Norm Jacobs]

I ran into this earlier in the week on the current Solaris development builds and I think that one of my co-workers was going to file a bug on it.  Basically, Solaris doesn't have an endian.h, so you have to patch include/llvm/Support/Host.h to define BYTE_ORDER as it would on linux and some other platforms.

--- llvm-3.3.src/include/llvm/Support/Host.h.orig    Mon Apr 15 15:13:59 2013
+++ llvm-3.3.src/include/llvm/Support/Host.h    Wed Jun 19 11:03:01 2013
@@ -18,6 +18,21 @@
 
 #if defined(__linux__)
 #include <endian.h>
+#elif defined(__sun) && defined(__SVR4)
+#  ifndef BYTE_ORDER
+#   define LITTLE_ENDIAN 1234
+#   define BIG_ENDIAN    4321
+
+#   if defined(__sun) && defined(__SVR4)
+#    include <sys/isa_defs.h>
+#    ifdef _LITTLE_ENDIAN
+#     define BYTE_ORDER LITTLE_ENDIAN
+#    endif
+#    ifdef _BIG_ENDIAN
+#     define BYTE_ORDER BIG_ENDIAN
+#    endif
+#   endif /* sun */
+#  endif /* BYTE_ORDER */
 #else
 #ifndef LLVM_ON_WIN32
 #include <machine/endian.h>

    -Norm

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Jorge Rodrigues]

Norm,

 

thanks for the help. Applying the fix solves the issue I mentioned but now I have more issues.

 

 I can install clang, but when running I cannot compile and link files.

If I compile with -c flag it works but compiling the following x.c file gives an error:

 

x.c:
int main(void)
{
  return 0;
}

 

> ./clang x.c
/project/helder/scratch/packages2/bin/ld: unrecognized option '-C'
/project/helder/scratch/packages2/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)

 

 

> ./clang -v x.c
clang version 3.3 (tags/RELEASE_33/final)
Target: i386-pc-solaris2.10
Thread model: posix
 "/project/helder/scratch/packages2/clang/bin/clang" -cc1 -triple i386-pc-solaris2.10 -emit-obj -mrelax-all -disable-free -main-file-name x.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.23 -v -resource-dir /project/helder/scratch/packages2/clang/bin/../lib/clang/3.3 -fdebug-compilation-dir /project/helder/scratch/packages2/clang/bin -ferror-limit 19 -fmessage-length 145 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/x-Owaa.H.o -x c x.c
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-pc-solaris2.10
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /project/helder/scratch/packages2/clang/bin/../lib/clang/3.3/include
 /usr/include
End of search list.
 "/project/helder/scratch/packages2/bin/ld" -C -e _start -Bdynamic --dynamic-linker /usr/lib/ld.so.1 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o /usr/gcc/4.5/lib/gcc/i386-pc-solaris2.10/4.5.2/crtbegin.o -L/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.10/4.5.2/ /tmp/x-Owaa.H.o -lgcc_s -lgcc -lc -lm /usr/gcc/4.5/lib/gcc/i386-pc-solaris2.10/4.5.2/crtend.o /usr/lib/crtn.o
/project/helder/scratch/packages2/bin/ld: unrecognized option '-C'
/project/helder/scratch/packages2/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any idea on how to solve this?

 

Thanks!

[Stefan Teleman]

On Mon, Jun 24, 2013 at 6:17 PM, Jorge Rodrigues <ske...@gmail.com> wrote:
> Norm,
>
> thanks for the help. Applying the fix solves the issue I mentioned but now I
> have more issues.
>
> I can install clang, but when running I cannot compile and link files.
> If I compile with -c flag it works but compiling the following x.c file
> gives an error:

> /project/helder/scratch/packages2/bin/ld: unrecognized option '-C'
> /project/helder/scratch/packages2/bin/ld: use the --help option for usage
> information
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)

-C is a flag for the Solaris linker only (/usr/bin/ld). It looks like
/project/helder/scratch/packages2/bin/ld is actually the GNU linker,
and it doesn't understand -C.

I'll file the bug about the endian stuff, but we'll also have to have
an <endian.h> in Solaris as well.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan....@gmail.com

[Jakob Stoklund Olesen]

On Jun 24, 2013, at 4:18 PM, Stefan Teleman <stefan....@gmail.com> wrote:

> I'll file the bug about the endian stuff, but we'll also have to have
> an <endian.h> in Solaris as well.

Do you still have issues after r182419?

commit 01ef4f6982451e6a7c00a713d9ae677d3a15d042
Author: Jakob Stoklund Olesen <stok...@2pi.dk>
Date: Tue May 21 13:36:13 2013

Define BYTE_ORDER on Solaris.

Solaris doesn't have an endian.h header, but SPARC is the only
big-endian architecture that runs Solaris, so just use that to detect
endianness at compile time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182419 91177308-0d34-0410-b5e6-96231b3b80d8

Thanks,
/jakob

[Jorge Rodrigues]

In the solaris machine I have access to I cannot use svn. I downloaded it at home tranfered with pen drive and now the compilations doesn't complain about endian.h missing.

The error now is

 

> make
make[1]: Entering directory `/project/helder/scratch/tmp/llvm/build/lib/Support'
llvm[1]: Compiling PathV2.cpp for Debug+Asserts build
In file included from /project/helder/scratch/tmp/llvm/lib/Support/PathV2.cpp:964:0:
/project/helder/scratch/tmp/llvm/lib/Support/Unix/PathV2.inc: In function 'llvm::error_code llvm::sys::fs::setLastModificationAndAccessTime(int, llvm::sys::TimeValue)':
/project/helder/scratch/tmp/llvm/lib/Support/Unix/PathV2.inc:452:7: error: '::futimes' has not been declared
   if (::futimes(FD, Times))
       ^
/project/aircrews/packages/sun/5.10/x86/gnu/bin/rm: cannot remove `/project/helder/scratch/tmp/llvm/build/lib/Support/Debug+Asserts/PathV2.d.tmp': No such file or directory
make[1]: *** [/project/helder/scratch/tmp/llvm/build/lib/Support/Debug+Asserts/PathV2.o] Error 1
make[1]: Leaving directory `/project/helder/scratch/tmp/llvm/build/lib/Support'

make: *** [all] Error 1

 

 

Thanks,

Jorge

[Jorge Rodrigues]

Is there anything I can do regarding the linker issue? The solaris linker is in /usr/ccs/bin/ld but I think llvm wants to use the gnu linker. gcc in my system was compiled with the solaris linker.

 

Thanks,

Jorge

[Stefan Teleman]

On Tue, Jun 25, 2013 at 10:50 AM, Jorge Rodrigues <ske...@gmail.com> wrote:
> Is there anything I can do regarding the linker issue? The solaris linker is
> in /usr/ccs/bin/ld but I think llvm wants to use the gnu linker. gcc in my
> system was compiled with the solaris linker.

The current Solaris implementation in
${top}/tools/clang/lib/Driver/Tools.cpp has all the GCC and
linker-related machinery hardcoded.

I have a number of patches for Solaris which would make all the linker
stuff work much better (and would give one the option to choose
between different linkers at link time) but I haven't gotten the green
light from Oracle to make these patches public yet - i'm waiting on
the internal approval chain to complete.

We *really* want to contribute Solaris support (Intel and SPARC) to
clang/llvm, and these legal approvals are not only required, but also
in everyone's best interests (not just our own).

i'm waiting for legal approvals at this point, and i don't have a
better solution handy at the moment. The only thing i can offer is
"stay tuned, we're working on it". :-)

--Stefan

--
Stefan Teleman
KDE e.V.
stefan....@gmail.com

[Jorge Rodrigues]

Hope you get the legal approvals,

 

until then I will wait.

 

--Jorge

[Jakob Stoklund Olesen]

On Jun 25, 2013, at 8:42 AM, Stefan Teleman <stefan....@gmail.com> wrote:

> On Tue, Jun 25, 2013 at 10:50 AM, Jorge Rodrigues <ske...@gmail.com> wrote:
>> Is there anything I can do regarding the linker issue? The solaris linker is
>> in /usr/ccs/bin/ld but I think llvm wants to use the gnu linker. gcc in my
>> system was compiled with the solaris linker.
>
> The current Solaris implementation in
> ${top}/tools/clang/lib/Driver/Tools.cpp has all the GCC and
> linker-related machinery hardcoded.
>
> I have a number of patches for Solaris which would make all the linker
> stuff work much better (and would give one the option to choose
> between different linkers at link time) but I haven't gotten the green
> light from Oracle to make these patches public yet - i'm waiting on
> the internal approval chain to complete.
>
> We *really* want to contribute Solaris support (Intel and SPARC) to
> clang/llvm, and these legal approvals are not only required, but also
> in everyone's best interests (not just our own).
>
> i'm waiting for legal approvals at this point, and i don't have a
> better solution handy at the moment. The only thing i can offer is
> "stay tuned, we're working on it". :-)

Sounds great!

Solaris is quite different from the usual crop of BSDs and Linuxen. If you want to make sure that LLVM and Clang stay working on Solaris, you should look into setting up a buildbot. Random stuff will keep breaking if it isn’t being tested continuously.

Bug reports and patches for the SPARC v9 support are also welcome ;-)

Thanks,
/jakob