similar to: [LLVMdev] Link tests are not allowed after GCC_NO_EXECUTABLES

On Sat, 20 Nov 2004, Henrik Bach wrote: > I can't figure what this means: > ------------------ > ... > checking for g++ that supports -ffunction-sections -fdata-sections... no > checking for sin in -lm... configure: error: Link tests are not allowed > after GCC_NO_EXECUTABLES. > make: *** [configure-target-libstdc++-v3] Error 1 > ------------------ I've never seen

Hi, John Chriswell wrote: >You might want to google for AC_NO_EXECUTABLES. It's an autoconf test that >generates the >behavior you describe. Apparently the GCC folks wrote a new >version of the macro due to the >above behavior. As suggested, I googled and found this interesting answer for above error and behavior: http://www.mail-archive.com/gcc-bugs at

I am now getting an X86ATTAsmPrinter error in compiling libstdc++-v3 right near the end of compiling llvm-gcc in valarray-inst.cc. assertion "IndexReg.getReg() != X86::ESP && "X86 doesn't allow scaling by ESP" Does this build on Linux ? My remote Linux box has died and not a ble to reset it for a day or two. /home/ang/build/llvm-gcc/./gcc/xgcc -shared-libgcc

I checked llvm-gcc 4.0 out from svn yesterday and am compiling it on 3 different machines. I was able to compile it on 2 of the machines, but the compilation failed on the third machine with the errors below. The machine that the compilation failed on is running Fedora Core 4. The processor is a AMD Athlon(tm) 64 Processor 3700+. The version of gcc I have on the machine is 4.0.2. I tried

Hi, I would like this patch for Path.inc to be accepted. I cannot tell, why the win32 version of isValid() method fails when issuing a correct path on the mingw platform. This is especially annoying when configuring the cfrontend, because we get this misindicating error: 'checking for sin in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.' And it has

Still trying to build the cfrontend on MinGW: checking for additional debug build... no checking for extra compiler flags for building... checking for sys/types.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for main in -lm...

Hello, It looks like compiler-rt CMake scripts don't take CMAKE_CXX_FLAGS into account. This is because clang_compile and clang_link_shared functions call the newly-built compiler directly, and they don't add those flags. Using CMAKE_CXX_FLAGS is necessary on systems where the C++11-enabled libstdc++ is installed not in the default location. For example, the CentOS buildbot uses:

Thanks for your tips. But I'm still getting errors. .../llvm-gcc4.2-2.6.source/configure --prefix=`pwd`/../install --program-prefix=llvm- --enable-llvm=/home/LLVM/llvm-2.6/ --enable-languages=c,c++  --with-gnu-ld=/home/arm/bin/arm-elf-ld --with-gnu-as=/home/arm/bin/arm-elf-as  --with-cpu=cortex-a8  --target=arm-elf Errors: >> checking for g++ that supports -ffunction-sections

On 5/7/2015 8:38 AM, Joerg Sonnenberger wrote: > On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote: >> The atom model allowed lld to have a single intermediate >> representation for all the formats ELF/COFF/Mach-O. The native model >> allowed the intermediate representation to be serialized to disk >> too. If the intermediate representations data

On Wed, 22 Aug 2007, Ryan M. Lefever wrote: > I checked llvm-gcc 4.0 out from svn yesterday and am compiling it on 3 > different machines. I was able to compile it on 2 of the machines, but > the compilation failed on the third machine with the errors below. The > machine that the compilation failed on is running Fedora Core 4. The > processor is a AMD Athlon(tm) 64 Processor

This looks like pr4572. Evan On Jul 27, 2009, at 3:25 AM, Aaron Gray wrote: > I am now getting an X86ATTAsmPrinter error in compiling libstdc++-v3 > right near the end of compiling llvm-gcc in valarray-inst.cc. > > assertion "IndexReg.getReg() != X86::ESP && "X86 doesn't allow > scaling by ESP" > > Does this build on Linux ? > > My

Hello I am trying to compile asterisk-oh323-0.7.0 with pwlib-Janus_patch4 and openh323-Janus_patch4 downloaded from inaccessnetworks so I did this: tar -zxvf openh323-Janus_patch4-src-tar.gz cd openh323 patch -p1 < /root/asterisk-oh323-0.7.0/openh323_1.13.5-make.patch ./configure make opt cd asterisk-oh323-0.7.0 vi Makefile (to set the paths and options according to my system...) NOW I

Chris, I'm a little confused. I am experiencing a crash when compiling the llvm-gcc frontend. According to the bugpoint documentation, bugpoint is used to debug "optimizer crashes, miscompilations by optimizers, or bad native code generation," which seems like it implies that the frontend compiles. Also, the http://llvm.org/docs/HowToSubmitABug.html documentation seems to

I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. The configuration is the following: LIBCXX_HAS_MUSL_LIBC=ON LIBCXX_HAS_GCC_S_LIB=OFF CLANG_DEFAULT_CXX_STDLIB=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64

hello all i am having a problem in compiling openh323. [root@kamran openh323]# ./configure checking for g++... g++ checking for C++ compiler default output... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes

On 7/30/2013 7:50 PM, Eric Christopher wrote: > On Tue, Jul 30, 2013 at 5:36 PM, Nick Kledzik <kledzik at apple.com> wrote: >> On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote: >>> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote: >>>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>>> Is there any reason

>>Does anyone know a source for a pre-built version of the same? > >To my knowledge there is no pre-built version of the cfe. See following link for CFE :- http://illuvium.com/download/ It maybe a bit out of date. I believe the CFE maybe broken at the moment, at least the Cygwin nightly test reports that it is broken and I believe this is the same thing ?

On 7/25/2013 3:56 PM, Rui Ueyama wrote: > I think I share the goal with you to make the foundation for better > dead-strip, so thank you for suggesting. I'm not sure if marking a section > as a whole as "safe" or "unsafe" is the best approach, though. Some > comments. > > - If the compiler generated code is always "safe", and if we can >

On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: > Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. >From my understanding, -ffunction-sections is a good semantic match. But it introduces a lot of bloat in

Hi everyone, Recently I tried to compile llvm-gcc-4.2-2.9 on a 64bit ubuntu12.04 machine. And I was using the settings below, export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu ../llvm-gcc-4.2-2.9.source/configure --enable-optimized --program-prefix=llvm- --enable-checking --enable-llvm=${HOME}/moonbox/llvm-obj/Debug+Asserts