search for: exported_symbols_list

...owing document provides good summary... http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html#/ /apple_ref/doc/uid/TP40001670 Another way to control symbol visibility is to use linker's interface. See ld man page for more info on -exported_symbols_list, - exported_symbols, -unexported_symbols_list etc.. flags. If you're going to try this approach, pl. read ld man page first. - Devang

On Sun, Jan 25, 2009 at 11:38:48AM +0100, Jean-Daniel Dupas wrote: > > Le 25 janv. 09 à 06:01, Jack Howarth a écrit : > > > After trying the recommended use of -O4 -fvisibility=hidden to > > compile xplor-nih with full LTO optimizations, I discovered three > > symbols become undefined... > > > > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ >

On Tue, Sep 06, 2005 at 08:54:18AM +1000, Jean-Marc Valin wrote: > I usually compile with several warning flags, but I prefer not to impose > any (especially since not everyone uses gcc!). FWIW, configure is already checking to see whether the compiler is gcc or not. There's an if clause in the configure scripts for ogg, vorbis, theora, and other of our packages that uses this to add

...filelist /Users/jeff/programming/xiph- qt/OggImport/build/OggImport.build/Development/OggImport.build/Objects- normal/i386/OggImport.LinkFileList -framework Carbon -framework CoreFoundation -framework QuickTime -framework Ogg -framework Vorbis - framework TheoraExp -framework Speex -arch i386 -exported_symbols_list src/OggImport.exp -bundle -mmacosx-version-min=10.4 -isysroot / Developer/SDKs/MacOSX10.4u.sdk Undefined symbols: "__store_sample_reference", referenced from: _process_stream_page__vorbis in stream_vorbis.o _process_stream_page__speex in stream_speex.o _process_...

...two mechanisms: 1) individual symbols can be marked never-dead-strip. This is set on Objective-C meta data (e.g. ObjC class data structures) because ObjC is a dynamic language where the only use of a class might be not know until runtime. 2) The linker may be passed a list of symbols to export (-exported_symbols_list). Those symbols are the dead strip roots. Typically usage is that a dylib has a fixed "interface" (API). Only those symbols are exported from the dylib. All others are marked hidden. And if the -dead_strip linker option is used, any atoms not reachable from the API atoms are dead str...

...summary... > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html#/ > /apple_ref/doc/uid/TP40001670 > > Another way to control symbol visibility is to use linker's interface. > See ld man page for more info on -exported_symbols_list, - > exported_symbols, -unexported_symbols_list etc.. flags. If you're > going to try this approach, pl. read ld man page first. > - > Devang > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu...

Hi Nick, Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) 2) Or, uses a list of names that are dead strip roots (other types) Question:- *********** How are the dead strip root names supposed to be

...filelist /Users/jeff/programming/xiph- qt/OggImport/build/OggImport.build/Development/OggImport.build/Objects- normal/i386/OggImport.LinkFileList -framework Carbon -framework CoreFoundation -framework QuickTime -framework Ogg -framework Vorbis - framework TheoraExp -framework Speex -arch i386 -exported_symbols_list src/OggImport.exp -bundle -mmacosx-version-min=10.4 -isysroot / Developer/SDKs/MacOSX10.4u.sdk Undefined symbols: "__store_sample_reference", referenced from: _process_stream_page__vorbis in stream_vorbis.o _process_stream_page__speex in stream_speex.o _process_...

...ibLLVM-$(LLVMVersion)$(SHLIBEXT) +LLVMLibsPaths += $(SharedDir)/$(SharedPrefix)LLVM-$(LLVMVersion)$(SHLIBEXT) else LLVMLibsOptions += $(shell $(LLVM_CONFIG) --libs $(LINK_COMPONENTS)) LLVMLibsPaths += $(LLVM_CONFIG) \ @@ -1018,6 +1046,21 @@ ifeq ($(HOST_OS),Darwin) LLVMLibsOptions += -Wl,-exported_symbols_list,$(NativeExportsFile) endif +# GNU ld Win32 accepts .DEF files that contain "DATA" entries. +ifeq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW)) +NativeExportsFile := $(ObjDir)/$(notdir $(EXPORTED_SYMBOL_FILE:.exports=.def)) + +# LLVMLibsOptions is invalidated at processing tools/llvm...

Hi Takumi, > Any feedbacks are welcome. > Have fun! This seems to be pretty useful addition to LLVM on windows! And it seems the only painless way to make plugins working, yay! For me the patch looks pretty good. One minor thing: could you please rename SharedDir => SharedLibDir Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

...LVM-$(LLVMVersion)$(SHLIBEXT) +LLVMLibsPaths += $(SharedLibDir)/$(SharedPrefix)LLVM-$(LLVMVersion)$(SHLIBEXT) else LLVMLibsOptions += $(shell $(LLVM_CONFIG) --libs $(LINK_COMPONENTS)) LLVMLibsPaths += $(LLVM_CONFIG) \ @@ -1018,6 +1047,21 @@ ifeq ($(HOST_OS),Darwin) LLVMLibsOptions += -Wl,-exported_symbols_list,$(NativeExportsFile) endif +# GNU ld Win32 accepts .DEF files that contain "DATA" entries. +ifeq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW)) +NativeExportsFile := $(ObjDir)/$(notdir $(EXPORTED_SYMBOL_FILE:.exports=.def)) + +# LLVMLibsOptions is invalidated at processing tools/llvm...

...-page-64.test lld :: elf/X86_64/sectionchoice.test lld :: elf/X86_64/sectionmap.test lld :: mach-o/arm-interworking.yaml lld :: mach-o/arm-shims.yaml lld :: mach-o/data-only-dylib.yaml lld :: mach-o/executable-exports.yaml lld :: mach-o/exe-offsets.yaml lld :: mach-o/exported_symbols_list-undef.yaml lld :: mach-o/fat-archive.yaml lld :: mach-o/flat_namespace_undef_error.yaml lld :: mach-o/flat_namespace_undef_suppress.yaml lld :: mach-o/force_load-x86_64.yaml lld :: mach-o/got-order.yaml lld :: mach-o/hello-world-arm64.yaml lld :: mach-o/hello-world-armv6...

....test > lld :: elf/X86_64/sectionchoice.test > lld :: elf/X86_64/sectionmap.test > lld :: mach-o/arm-interworking.yaml > lld :: mach-o/arm-shims.yaml > lld :: mach-o/data-only-dylib.yaml > lld :: mach-o/executable-exports.yaml > lld :: mach-o/exe-offsets.yaml > lld :: mach-o/exported_symbols_list-undef.yaml > lld :: mach-o/fat-archive.yaml > lld :: mach-o/flat_namespace_undef_error.yaml > lld :: mach-o/flat_namespace_undef_suppress.yaml > lld :: mach-o/force_load-x86_64.yaml > lld :: mach-o/got-order.yaml > lld :: mach-o/hello-world-arm64.yaml > lld :: mach-o/hello-worl...

...lld :: elf/X86_64/sectionmap.test >> lld :: mach-o/arm-interworking.yaml >> lld :: mach-o/arm-shims.yaml >> lld :: mach-o/data-only-dylib.yaml >> lld :: mach-o/executable-exports.yaml >> lld :: mach-o/exe-offsets.yaml >> lld :: mach-o/exported_symbols_list-undef.yaml >> lld :: mach-o/fat-archive.yaml >> lld :: mach-o/flat_namespace_undef_error.yaml >> lld :: mach-o/flat_namespace_undef_suppress.yaml >> lld :: mach-o/force_load-x86_64.yaml >> lld :: mach-o/got-order.yaml >> lld :: mach-o/hell...

Hi Rui, et al., I was experimenting yesterday with building lld on my POWER7 PPC64/Linux machine, and ran into an unfortunate problem. When running the regressions tests under lit, almost all of the tests fail like this: terminate called after throwing an instance of 'std::system_error' what(): Resource temporarily unavailable ... 5 libc.so.6 0x00000080b7847238 abort +

...pipes... /bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking for dsymutil... dsymutil checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for -force_load linker flag... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fno-common -DPIC checking if gcc PIC flag -fno-common -DPIC works... yes check...

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

...w to recognize dependent libraries... pass_all checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -p output from gcc object... ok checking for dsymutil... dsymutil checking for nmedit... nmedit checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes...

...w to recognize dependent libraries... pass_all checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -p output from gcc object... ok checking for dsymutil... dsymutil checking for nmedit... nmedit checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes...