Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

problem with -filelist option with XE Composer 2016 on Mac

chinhster
Beginner
434 Views

I'm currently using the deprecated stdc++ library in my Mac app. I want to switch to libc++ but now my application compiled with icc crashes when using a c++ library (it does not crash when launched, only when using some c++ libraries like libxl and boost):

 

libc++abi.dylib: terminating with uncaught exception of type libxl::xlerror: invalid file format

 

That same code compiled/linked with clang does not crash. It also doesn't crash if I go back to using libstdc++. I should also mention that there are some objective-c files that are compiled with the option -x objective-c.

 

I use an Xcode project for building the console version of my application but I also have a makefile I can use to build it too. When I use the makefile, the executable it builds does not crash and there's a pretty significant difference in executable size (the makefile built version is larger). After verifying all compiler and linker flags are the same between the Xcode project and the makefile and even swapping object code produced by both methods yet still getting the different performing executables and executable sizes, I finally determined that the -filelist option is the problem.

 

icc -filelist foo.LinkFileList -o foo (foo.LinkFileList contains the lines foo1.o, foo2.o, foo3.o) produces a different executable than icc foo1.o foo2.o foo3.o -o foo. The -filelist option produces a smaller executable that crashes when calling the c++ libraries like libxl and boost. To verify this, I built my application with the makefile and verified that it did not produce a crash. I then created a file containing a list of all of the object files and manually linked the executable using the -filelist option. That executable produced a crash. I then manually linked the executable without the -filelist option by entering all the object files as part of the linking command. That executable did not produce a crash.

 

I must use Xcode to build my application because my application consists of a GUI application and a console application. The GUI application has the same crashing problem when built with icc but I do not have a makefile to build it nor do I have any desire to create one. I only have the makefile for the console application. As far as I can tell, Xcode insists on using the -filelist option when linking.

 

I've verified the problem with icc v16.0.1 and icc v16.0.3 on the Mac. The reason I want to make the switch to libc++ is that Xcode 8 beta warns me that libstdc++ is deprecated. I've included an example that shows -filelist producing a different executable.

 

foo.c:

#include <stdio.h>
#include "bar.h"

int main(int argc, char *argv[])
{
        display_message();
        return 0;
}

 

bar.c:

#include <stdio.h>
#include "bar.h"

void display_message(void)
{
        printf("Hello world!\n");
}

 

list:

foo.o
bar.o

 

> icc --version
icc (ICC) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

​> icc -stdlib=libc++ -c foo.c 
> icc -x objective-c -stdlib=libc++ -c bar.c 
> icc -stdlib=libc++ -filelist list -lc++ -o foo
> icc -stdlib=libc++ foo.o bar.o -lc++ -o foo1
> otool -L foo foo1
foo:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
foo1:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
> diff foo foo1
Binary files foo and foo1 differ
> icc -stdlib=libc++ -c bar.c
> icc -stdlib=libc++ -filelist list -lc++ -o foo
> icc -stdlib=libc++ foo.o bar.o -lc++ -o foo1
> diff foo foo1
<no output which means they're the same>

 

0 Kudos
2 Replies
chinhster
Beginner
434 Views

Tech support notified me that when using the -filelist option, icc sends -no_compact_unwind to ld. After some testing, I've determined that the combination of -no_compact_unwind and linking to libc++ are the source of the crash. The crash happens regardless of whether I use icc or clang for the compiler. However, I have to explicitly add that option when compiling with clang whereas icc is implicitly adding the option for me.

 

I have no idea why icc sends -no_compact_unwind to ld when using the -filelist option. I've asked Intel to either stop doing that or give us an option to disable it. I also tried adding -mGLOB_no_compact_unwind=FALSE to both icpc.cfg and icc.cfg but that didn't help.

 

So the problem is that using the option -no_compact_unwind in ld causes problems with my app when linked against libc++. icc sends that option to ld when using the -filelist option and there's no way for me to prevent it from doing that that I know of.

0 Kudos
chinhster
Beginner
434 Views

I've found a solution. Use -Wl,-keep_dwarf_unwind.

 

The comments by user bdash at https://github.com/rust-lang/rust/issues/6849 explains what's going on and how to fix it.

 
0 Kudos
Reply