Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

The patches in SVN have a bug: 4.0 is using LLVM_3.9 for libllvm 
(simple_version_script.map), though the correct LLVM_4.0 elsewhere 
(AddLLVM.cmake).


The override_dh_makeshlibs/1:x symbols minimum version are needed in all 
versions, not just 3.8.



Also, #857623 (the OpenCL bug) also affects 3.8 and 4.0; the same fix
should work.

This has not yet been done.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Thanks, but I think we missed something: as packages rebuilt against new 
(versioned-symbols) LLVM don't work with old LLVM, we need a shlibs bump 
to make dependencies reflect that (i.e. require upgrading 
libllvm/libclang before their dependencies).  I think that's


--- /dev/null
+++ a/debian/liblldb-3.9.shlibs
@@ -0,0 +1 @@
+liblldb-3.9 1 liblldb-3.9 (>= 1:3.9.1-6~)
--- /dev/null
+++ a/debian/libllvm3.9.shlibs
@@ -0,0 +1 @@
+libLLVM-3.9 1 libllvm3.9 (>= 1:3.9.1-6~)

and either change every symbol's minimum version in 
libclang1-X.Y.symbols.in to 1:3.9.1-6~, or delete the symbols file (why 
does a library this API-unstable even have one?) and create a shlibs 
file similar to the above.  However, I have not tested this.


dh_makeshlibs -V in debian/rules would also work, but would become 
unnecessarily restrictive if future versions retain it.


Also, #857623 (the OpenCL bug) also affects 3.8 and 4.0; the same fix 
should work.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Rebuilding beignet and mesa against this llvm succeeds, and this beignet 
works.  (beignet is statically linked to LLVM/Clang, so we can't use it 
as a test of whether non-rebuilt rdeps work.)


blender+pocl-opencl-icd still crashes, with the bad jump being from 3.8 
to a versioned 3.9 symbol, but I suspect that just means LLVM 3.8 also 
needs a similar fix (possibly even the same one - I didn't try mostly 
because that means another hours-long build).


blender without pocl-opencl-icd works, with either rebuilt or 
non-rebuilt mesa, but given that this is in a chroot drawing to a Xephyr 
window, it may not be a good test of mesa.


$ cat /tmp/blender.crash.txt
# Blender 2.78 (sub 0), Unknown revision

# backtrace
blender(BLI_system_backtrace+0x30) [0x7f3dc227fec0]
blender(+0x1023101) [0x7f3dc1828101]
/lib/x86_64-linux-gnu/libc.so.6(+0x33040) [0x7f3db6597040]
/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1(_ZN4llvm2cl6Option9setArgStrENS_9StringRefE+0x9d) 
[0x7f3d8f2d2eed]

/usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1(+0x54f10b) [0x7f3d83a9b10b]
/usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1(+0x54f348) [0x7f3d83a9b348]
/lib64/ld-linux-x86-64.so.2(+0xf64a) [0x7f3dc05ee64a]
[...]
$ objdump -T /usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1 | grep 
_ZN4llvm2cl6Option9setArgStrENS_9StringRefE
0069ae50 gDF .text	034d  LLVM_3.9 
_ZN4llvm2cl6Option9setArgStrENS_9StringRefE

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

On 19/03/17 16:09, Sylvestre Ledru wrote:

Indeed. Are you going to update the symbol file?


I just deleted the symbols file to get the build to finish (which it 
did, and objdump -T confirmed that libLLVM and libclang had versioned 
symbols), but if you want to keep it, here's the full patch from the 
build log (1:3.9.1-5local2 will obviously be 1:3.9.1-6 in the final 
package):


--- debian/libclang1-3.9.symbols (libclang1-3.9_1:3.9.1-5local2_amd64)
+++ dpkg-gensymbolsd20Wgc   2017-03-19 15:49:47.859944671 +
@@ -1,340 +1,680 @@
 libclang-3.9.so.1 libclang1-3.9 #MINVER#
- clang_BlockCommandComment_getArgText@Base 3.2
- clang_BlockCommandComment_getCommandName@Base 3.2
- clang_BlockCommandComment_getNumArgs@Base 3.2
- clang_BlockCommandComment_getParagraph@Base 3.2
- clang_CXCursorSet_contains@Base 3.2
- clang_CXCursorSet_insert@Base 3.2
- clang_CXIndex_getGlobalOptions@Base 3.2
- clang_CXIndex_setGlobalOptions@Base 3.2
- clang_CXXConstructor_isConvertingConstructor@Base 3.9
- clang_CXXConstructor_isCopyConstructor@Base 3.9
- clang_CXXConstructor_isDefaultConstructor@Base 3.9
- clang_CXXConstructor_isMoveConstructor@Base 3.9
- clang_CXXField_isMutable@Base 3.8
- clang_CXXMethod_isConst@Base 3.4
- clang_CXXMethod_isDefaulted@Base 3.9
- clang_CXXMethod_isPureVirtual@Base 3.4
- clang_CXXMethod_isStatic@Base 3.2
- clang_CXXMethod_isVirtual@Base 3.2
- clang_Comment_getChild@Base 3.2
- clang_Comment_getKind@Base 3.2
- clang_Comment_getNumChildren@Base 3.2
- clang_Comment_isWhitespace@Base 3.2
- clang_CompilationDatabase_dispose@Base 3.2
- clang_CompilationDatabase_fromDirectory@Base 3.2
- clang_CompilationDatabase_getAllCompileCommands@Base 3.4
- clang_CompilationDatabase_getCompileCommands@Base 3.2
- clang_CompileCommand_getArg@Base 3.2
- clang_CompileCommand_getDirectory@Base 3.2
- clang_CompileCommand_getFilename@Base 3.8
- clang_CompileCommand_getMappedSourceContent@Base 3.8
- clang_CompileCommand_getMappedSourcePath@Base 3.8
- clang_CompileCommand_getNumArgs@Base 3.2
- clang_CompileCommands_dispose@Base 3.2
- clang_CompileCommands_getCommand@Base 3.2
- clang_CompileCommands_getSize@Base 3.2
- clang_Cursor_Evaluate@Base 3.9
- clang_Cursor_getArgument@Base 3.2
- clang_Cursor_getBriefCommentText@Base 3.2
- clang_Cursor_getCXXManglings@Base 3.8
- clang_Cursor_getCommentRange@Base 3.2
- clang_Cursor_getMangling@Base 3.6
- clang_Cursor_getModule@Base 3.2
- clang_Cursor_getNumArguments@Base 3.2
- clang_Cursor_getNumTemplateArguments@Base 3.6
- clang_Cursor_getObjCDeclQualifiers@Base 3.4
- clang_Cursor_getObjCPropertyAttributes@Base 3.4
- clang_Cursor_getObjCSelectorIndex@Base 3.2
- clang_Cursor_getOffsetOfField@Base 3.7
- clang_Cursor_getParsedComment@Base 3.2
- clang_Cursor_getRawCommentText@Base 3.2
- clang_Cursor_getReceiverType@Base 3.2
- clang_Cursor_getSpellingNameRange@Base 3.2
- clang_Cursor_getStorageClass@Base 3.6
- clang_Cursor_getTemplateArgumentKind@Base 3.6
- clang_Cursor_getTemplateArgumentType@Base 3.6
- clang_Cursor_getTemplateArgumentUnsignedValue@Base 3.6
- clang_Cursor_getTemplateArgumentValue@Base 3.6
- clang_Cursor_getTranslationUnit@Base 3.2
- clang_Cursor_hasAttrs@Base 3.9
- clang_Cursor_isAnonymous@Base 3.7
- clang_Cursor_isBitField@Base 3.4
- clang_Cursor_isDynamicCall@Base 3.2
- clang_Cursor_isFunctionInlined@Base 3.9
- clang_Cursor_isMacroBuiltin@Base 3.9
- clang_Cursor_isMacroFunctionLike@Base 3.9
- clang_Cursor_isNull@Base 3.2
- clang_Cursor_isObjCOptional@Base 3.4
- clang_Cursor_isVariadic@Base 3.4
- clang_EvalResult_dispose@Base 3.9
- clang_EvalResult_getAsDouble@Base 3.9
- clang_EvalResult_getAsInt@Base 3.9
- clang_EvalResult_getAsStr@Base 3.9
- clang_EvalResult_getKind@Base 3.9
- clang_File_isEqual@Base 3.6
- clang_FullComment_getAsHTML@Base 3.2
- clang_FullComment_getAsXML@Base 3.2
- clang_HTMLStartTagComment_isSelfClosing@Base 3.2
- clang_HTMLStartTag_getAttrName@Base 3.2
- clang_HTMLStartTag_getAttrValue@Base 3.2
- clang_HTMLStartTag_getNumAttrs@Base 3.2
- clang_HTMLTagComment_getAsString@Base 3.2
- clang_HTMLTagComment_getTagName@Base 3.2
- clang_IndexAction_create@Base 3.2
- clang_IndexAction_dispose@Base 3.2
- clang_InlineCommandComment_getArgText@Base 3.2
- clang_InlineCommandComment_getCommandName@Base 3.2
- clang_InlineCommandComment_getNumArgs@Base 3.2
- clang_InlineCommandComment_getRenderKind@Base 3.2
- clang_InlineContentComment_hasTrailingNewline@Base 3.2
- clang_Location_isFromMainFile@Base 3.4
- clang_Location_isInSystemHeader@Base 3.4
- clang_ModuleMapDescriptor_create@Base 3.6
- clang_ModuleMapDescriptor_dispose@Base 3.6
- clang_ModuleMapDescriptor_setFrameworkModuleName@Base 3.6
- clang_ModuleMapDescriptor_setUmbrellaHeader@Base 3.6
- clang_ModuleMapDescriptor_writeToBuffer@Base 3.6
- clang_Module_getASTFile@Base 3.4
- clang_Module_getFullName@Base 3.2
- clang_Module_getName@Base 3.2
- clang_Module_getNumTopLevelHeaders@Base 3.2
- clang_Module_getParent@Base 3.2
- clang_Module_getTopLevelHeader@Base 3.2
- clang_Module_isSystem@Base 3.6
- 

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 19/03/2017 à 17:02, Rebecca N. Palmer a écrit :
> 12 clang tests "unexpectedly" fail, but they're the same 12 that do so
> in the existing package:
> Failing Tests (12):
> Clang :: CodeGen/linux-arm-atomic.c
> Clang :: Driver/arm-cortex-cpus.c
> Clang :: Driver/arm-features.c
> Clang :: Driver/arm-ias-Wa.s
> Clang :: Driver/arm-mfpu.c
> Clang :: Driver/cross-linux.c
> Clang :: Driver/mips-as.c
> Clang :: Driver/mips-integrated-as.s
> Clang :: Preprocessor/arm-acle-6.5.c
> Clang :: Preprocessor/arm-target-features.c
> Clang :: Sema/builtins.c
> Clang :: SemaCXX/warn-memsize-comparison.cpp
>
>   Expected Passes: 9572
>   Expected Failures  : 16
>   Unsupported Tests  : 40
>   Unexpected Failures: 12
>
> The build then fails for symbols mismatch...with what looks like
> exactly the change we *want*:
>
> (last few of many)
> + clang_saveTranslationUnit@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_sortCodeCompletionResults@Base 3.2
> + clang_sortCodeCompletionResults@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_toggleCrashRecovery@Base 3.2
> + clang_toggleCrashRecovery@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_tokenize@Base 3.2
> + clang_tokenize@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_visitChildren@Base 3.2
> + clang_visitChildren@LLVM_3.9 1:3.9.1-5local2
> +#MISSING: 1:3.9.1-5local2# clang_visitChildrenWithBlock@Base 3.2
> + clang_visitChildrenWithBlock@LLVM_3.9 1:3.9.1-5local2
> dh_makeshlibs: failing due to earlier errors
>
Indeed. Are you going to update the symbol file?

Many thanks again!

S

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

12 clang tests "unexpectedly" fail, but they're the same 12 that do so 
in the existing package:

Failing Tests (12):
Clang :: CodeGen/linux-arm-atomic.c
Clang :: Driver/arm-cortex-cpus.c
Clang :: Driver/arm-features.c
Clang :: Driver/arm-ias-Wa.s
Clang :: Driver/arm-mfpu.c
Clang :: Driver/cross-linux.c
Clang :: Driver/mips-as.c
Clang :: Driver/mips-integrated-as.s
Clang :: Preprocessor/arm-acle-6.5.c
Clang :: Preprocessor/arm-target-features.c
Clang :: Sema/builtins.c
Clang :: SemaCXX/warn-memsize-comparison.cpp

  Expected Passes: 9572
  Expected Failures  : 16
  Unsupported Tests  : 40
  Unexpected Failures: 12

The build then fails for symbols mismatch...with what looks like exactly 
the change we *want*:


(last few of many)
+ clang_saveTranslationUnit@LLVM_3.9 1:3.9.1-5local2
+#MISSING: 1:3.9.1-5local2# clang_sortCodeCompletionResults@Base 3.2
+ clang_sortCodeCompletionResults@LLVM_3.9 1:3.9.1-5local2
+#MISSING: 1:3.9.1-5local2# clang_toggleCrashRecovery@Base 3.2
+ clang_toggleCrashRecovery@LLVM_3.9 1:3.9.1-5local2
+#MISSING: 1:3.9.1-5local2# clang_tokenize@Base 3.2
+ clang_tokenize@LLVM_3.9 1:3.9.1-5local2
+#MISSING: 1:3.9.1-5local2# clang_visitChildren@Base 3.2
+ clang_visitChildren@LLVM_3.9 1:3.9.1-5local2
+#MISSING: 1:3.9.1-5local2# clang_visitChildrenWithBlock@Base 3.2
+ clang_visitChildrenWithBlock@LLVM_3.9 1:3.9.1-5local2
dh_makeshlibs: failing due to earlier errors

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Looks like this is a known cowdancer issue (#640684 - fixed only for 
cowbuilder --build, not --login); continuing with LD_PRELOAD= 
debian/rules build, the LLVM tests pass:


  Expected Passes: 16742
  Expected Failures  : 124
  Unsupported Tests  : 339
  Unexpected Passes  : 17

Still building the clang tests...

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 19/03/2017 à 15:46, Rebecca N. Palmer a écrit :
>> What do you mean by "not tested" ? You did built it right?
> Not as of that message.
>
> I since tried to build the "version script" option: it failed most of
> its tests with
> -- 
> Exit Code: 126
>
> Command Output (stderr):
> -- 
> E: env var COWDANCER_ILISTFILE not defined
> E: cowdancer: Fatal, initialize_functions failed
> E: env var COWDANCER_ILISTFILE not defined
> E: env var COWDANCER_ILISTFILE not defined
> E: env var COWDANCER_ILISTFILE not defined
> /bin/bash:
> /home/rnpalmer/Debian/builds/stackbuild/llvm-toolchain-3.9-3.9.1/build-llvm/test/CodeGen/X86/Output/2008-04-09-BranchFolding.ll.script:
> Cannot allocate memory 
First time that I see that error
and LLVM should not have any test failing

S

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

What do you mean by "not tested" ? You did built it right?

Not as of that message.

I since tried to build the "version script" option: it failed most of 
its tests with

--
Exit Code: 126

Command Output (stderr):
--
E: env var COWDANCER_ILISTFILE not defined
E: cowdancer: Fatal, initialize_functions failed
E: env var COWDANCER_ILISTFILE not defined
E: env var COWDANCER_ILISTFILE not defined
E: env var COWDANCER_ILISTFILE not defined
/bin/bash: 
/home/rnpalmer/Debian/builds/stackbuild/llvm-toolchain-3.9-3.9.1/build-llvm/test/CodeGen/X86/Output/2008-04-09-BranchFolding.ll.script: 
Cannot allocate memory


  Expected Passes: 1550
  Expected Failures  : 141
  Unsupported Tests  : 339
  Unexpected Failures: 15192

(dpkg-buildpackage -us -uc inside cowbuilder --login (*not* --build), 
4GB RAM)


That looks like an environment problem, but as this was my first attempt 
to build LLVM, I don't know for sure.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 19/03/2017 à 11:13, Rebecca N. Palmer a écrit :
> Here's the 'version script' solution, now covering libLLVM, libclang,
> liblldb, libLTO, BugpointPasses, LLVMHello and LLVMgold (I suspect
> only the first 2-3 actually have use for it, but all except the first
> are set from the same place).
>
> Warning: this hasn't been tested either, and the
> cmake/modules/AddLLVM.cmake modified here gets shipped in llvm-3.9-dev.
>
Looks great, well done for this great work!
What do you mean by "not tested" ? You did built it right?

S

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Here's the 'version script' solution, now covering libLLVM, libclang, 
liblldb, libLTO, BugpointPasses, LLVMHello and LLVMgold (I suspect only 
the first 2-3 actually have use for it, but all except the first are set 
from the same place).


Warning: this hasn't been tested either, and the 
cmake/modules/AddLLVM.cmake modified here gets shipped in llvm-3.9-dev.


The full list of .so libraries built from llvm-toolchain-3.9:
llvm-3.9-dev:
./usr/lib/llvm-3.9/lib/libLTO.so 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/tools/lto/LTO.exports
./usr/lib/llvm-3.9/lib/BugpointPasses.so 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/tools/bugpoint-passes/BugpointPasses.exports
./usr/lib/llvm-3.9/lib/LLVMHello.so 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/lib/Transforms/Hello/LLVMHello.exports
./usr/lib/llvm-3.9/lib/LLVMPolly.so none, linked from 
build-llvm/tools/polly/lib
./usr/lib/llvm-3.9/lib/LLVMgold.so 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/tools/gold/LLVMgold.exports

libllvm3.9:
./usr/lib/i386-linux-gnu/libLLVM-3.9.so.1
liblldb-3.9:
./usr/lib/llvm-3.9/lib/python2.7/site-packages/readline.so none, linked 
from build-llvm/tools/lldb/scripts/Python/modules/readline
./usr/lib/i386-linux-gnu/liblldb-3.9.so.1 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/tools/lldb/source/API/liblldb.exports

libclang1-3.9:
./usr/lib/i386-linux-gnu/libclang-3.9.so.1 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/tools/clang/tools/libclang/libclang.exports

libclang-common-3.9-dev:
./usr/lib/llvm-3.9/lib/clang/3.9.1/lib/linux/libclang_rt.dyndd-x86_64.so 
(only, though this is from the i386 build log...) none, linked from 
build-llvm/projects/compiler-rt/lib/tsan/dd
./usr/lib/llvm-3.9/lib/clang/3.9.1/lib/linux/libclang_rt.asan-x86_64.so 
-Wl,--version-script,/«PKGBUILDDIR»/build-llvm/projects/compiler-rt/lib/asan/clang_rt.asan-dynamic-x86_64.vers
./usr/lib/llvm-3.9/lib/clang/3.9.1/lib/linux/libclang_rt.asan-i686.so 
none, linked from build-llvm/projects/compiler-rt/lib/asan
./usr/lib/llvm-3.9/lib/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so 
none, linked from build-llvm/projects/compiler-rt/lib/asan
diff -Nru llvm-toolchain-3.9-3.9.1/debian/changelog 
llvm-toolchain-3.9-3.9.1/debian/changelog
--- llvm-toolchain-3.9-3.9.1/debian/changelog   2017-03-12 09:01:10.0 
+
+++ llvm-toolchain-3.9-3.9.1/debian/changelog   2017-03-19 09:48:56.0 
+
@@ -1,3 +1,11 @@
+llvm-toolchain-3.9 (1:3.9.1-5local2) UNRELEASED; urgency=medium
+
+  * Allow '!pointer' in OpenCL (Closes: #857623)
+  * Add missing liblldb symlink (Closes: #857683)
+  * Use versioned symbols (Closes: #848368)
+
+ -- Rebecca N. Palmer   Sat, 18 Mar 2017 21:29:25 
+
+
 llvm-toolchain-3.9 (1:3.9.1-5) unstable; urgency=medium
 
   * Fix the incorrect symlink to scan-build-py (Closes: #856869)
diff -Nru llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in 
llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in
--- llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in2016-08-08 
16:02:20.0 +0100
+++ llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in2017-03-19 
09:47:46.0 +
@@ -1,3 +1,4 @@
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb-@LLVM_VERSION@.so.1
 
diff -Nru 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
--- 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
1970-01-01 01:00:00.0 +0100
+++ 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
2017-03-19 09:47:46.0 +
@@ -0,0 +1,20 @@
+Description: Allow "if (!pointer)" in OpenCL 1.1
+
+Used by e.g. Blender on mesa-opencl-icd
+
+Author: Anastasia Stulova
+Origin: upstream https://reviews.llvm.org/rL294313
+Bug: https://bugs.llvm.org/show_bug.cgi?id=30217
+Bug-Debian: https://bugs.debian.org/857623
+
+--- llvm-toolchain-3.9-3.9.1.orig/clang/lib/Sema/SemaExpr.cpp
 llvm-toolchain-3.9-3.9.1/clang/lib/Sema/SemaExpr.cpp
+@@ -11424,7 +11424,7 @@ ExprResult Sema::CreateBuiltinUnaryOp(So
+  Context.getLangOpts().OpenCLVersion < 120) {
+ // OpenCL v1.1 6.3.h: The logical operator not (!) does not
+ // operate on scalar float types.
+-if (!resultType->isIntegerType())
++if (!resultType->isIntegerType() && !resultType->isPointerType())
+   return ExprError(Diag(OpLoc, diag::err_typecheck_unary_expr)
+<< resultType << Input.get()->getSourceRange());
+   }
diff -Nru llvm-toolchain-3.9-3.9.1/debian/patches/add_symbols_versioning.patch 

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 18/03/2017 à 23:40, Rebecca N. Palmer a écrit :
> Can this be fixed in time for Ubuntu 17.04?  Their mesa is built against LLVM 
> 4.0, so if this bug isn't fixed, I (as beignet maintainer) have to choose 
> between "apply a very new 4.0-support patch that might or might not work" and 
> "leave beignet on 3.9, making OpenCL+OpenGL applications (e.g.
> blender) subject to this bug".
> 
>> I've been told that there is a command line to add a version to all symbols
>> without a script, that should be enough at least for Debian packaging.
> -Wl,--default-symver : rarely used (only 5 packages), and forces the symbol 
> version to be the soname (i.e. libLLVM-3.9.so.1) rather than the conventional 
> LLVM_3.9 form (i.e. potential binary incompatibility if upstream later decide 
> to do it the conventional way), but should at least fix this crash.
> 
> The attached debdiff is for this option, and also fixes #857623 and #857683.  
> Warning: has NOT been tested yet.
> 
> I intend to try extending the earlier "version script" patch to also cover 
> libclang and liblldb tomorrow.

Impressive! I believe we can try this solution. Many thanks.
I started to build this myself.

If it is working file, I will discuss with upstream about integrating that!
Bravo,
Sylvestre

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Can this be fixed in time for Ubuntu 17.04?  Their mesa is built against 
LLVM 4.0, so if this bug isn't fixed, I (as beignet maintainer) have to 
choose between "apply a very new 4.0-support patch that might or might 
not work" and "leave beignet on 3.9, making OpenCL+OpenGL applications 
(e.g. blender) subject to this bug".



I've been told that there is a command line to add a version to all symbols
without a script, that should be enough at least for Debian packaging.
-Wl,--default-symver : rarely used (only 5 packages), and forces the 
symbol version to be the soname (i.e. libLLVM-3.9.so.1) rather than the 
conventional LLVM_3.9 form (i.e. potential binary incompatibility if 
upstream later decide to do it the conventional way), but should at 
least fix this crash.


The attached debdiff is for this option, and also fixes #857623 and 
#857683.  Warning: has NOT been tested yet.


I intend to try extending the earlier "version script" patch to also 
cover libclang and liblldb tomorrow.
diff -Nru llvm-toolchain-3.9-3.9.1/debian/changelog 
llvm-toolchain-3.9-3.9.1/debian/changelog
--- llvm-toolchain-3.9-3.9.1/debian/changelog   2017-03-12 09:01:10.0 
+
+++ llvm-toolchain-3.9-3.9.1/debian/changelog   2017-03-18 21:33:53.0 
+
@@ -1,3 +1,11 @@
+llvm-toolchain-3.9 (1:3.9.1-5local1) UNRELEASED; urgency=medium
+
+  * Allow '!pointer' in OpenCL (Closes: #857623)
+  * Add missing liblldb symlink (Closes: #857683)
+  * Use versioned symbols (Closes: #848368)
+
+ -- Rebecca N. Palmer   Sat, 18 Mar 2017 21:29:25 
+
+
 llvm-toolchain-3.9 (1:3.9.1-5) unstable; urgency=medium
 
   * Fix the incorrect symlink to scan-build-py (Closes: #856869)
diff -Nru llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in 
llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in
--- llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in2016-08-08 
16:02:20.0 +0100
+++ llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y.links.in2017-03-18 
17:33:17.0 +
@@ -1,3 +1,4 @@
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb-@LLVM_VERSION@.so.1
 
diff -Nru 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
--- 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
1970-01-01 01:00:00.0 +0100
+++ 
llvm-toolchain-3.9-3.9.1/debian/patches/857623-allow-opencl-pointer-to-bool.diff
2017-03-18 21:25:52.0 +
@@ -0,0 +1,20 @@
+Description: Allow "if (!pointer)" in OpenCL 1.1
+
+Used by e.g. Blender on mesa-opencl-icd
+
+Author: Anastasia Stulova
+Origin: upstream https://reviews.llvm.org/rL294313
+Bug: https://bugs.llvm.org/show_bug.cgi?id=30217
+Bug-Debian: https://bugs.debian.org/857623
+
+--- llvm-toolchain-3.9-3.9.1.orig/clang/lib/Sema/SemaExpr.cpp
 llvm-toolchain-3.9-3.9.1/clang/lib/Sema/SemaExpr.cpp
+@@ -11424,7 +11424,7 @@ ExprResult Sema::CreateBuiltinUnaryOp(So
+  Context.getLangOpts().OpenCLVersion < 120) {
+ // OpenCL v1.1 6.3.h: The logical operator not (!) does not
+ // operate on scalar float types.
+-if (!resultType->isIntegerType())
++if (!resultType->isIntegerType() && !resultType->isPointerType())
+   return ExprError(Diag(OpLoc, diag::err_typecheck_unary_expr)
+<< resultType << Input.get()->getSourceRange());
+   }
diff -Nru llvm-toolchain-3.9-3.9.1/debian/patches/series 
llvm-toolchain-3.9-3.9.1/debian/patches/series
--- llvm-toolchain-3.9-3.9.1/debian/patches/series  2017-01-27 
09:03:47.0 +
+++ llvm-toolchain-3.9-3.9.1/debian/patches/series  2017-03-18 
21:20:57.0 +
@@ -47,3 +47,4 @@
 amdgpu-regression.diff
 esan-Fix-ESan-test-failure-on-Debian-Sid-bot.diff
 esan-Fix-ESan-test-failure-on-Debian-Sid-bot2.diff
+857623-allow-opencl-pointer-to-bool.diff
diff -Nru llvm-toolchain-3.9-3.9.1/debian/rules 
llvm-toolchain-3.9-3.9.1/debian/rules
--- llvm-toolchain-3.9-3.9.1/debian/rules   2017-01-26 08:35:04.0 
+
+++ llvm-toolchain-3.9-3.9.1/debian/rules   2017-03-18 17:25:11.0 
+
@@ -24,7 +24,7 @@
 
 OCAML_STDLIB_DIR?= $(shell ocamlc -where)
 
-LDFLAGS_EXTRA =
+LDFLAGS_EXTRA = -Wl,--default-symver
 CXXFLAGS_EXTRA = -std=c++0x
 CONFIGURE_EXTRA =
 CMAKE_EXTRA =

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

tag 848368 - patch
thanks

I have tested the patch and indeed it only works on libllvm, so removing the 
patch tag for now.

On domingo, 22 de enero de 2017 21:31:08 ART Rebecca N. Palmer wrote:
> On 22/01/17 21:07, Sylvestre Ledru wrote:
> > , you haven't pass the arg to LDFLAGS to make sure that libclang or
> > liblldb get it,
> > is that on purpose?
> 
> My original intent was to avoid passing it to those parts of LLVM that
> already use a "version" (actually which-symbols-are-public) script, as
> I suspect having two version scripts is an error; you're right that
> there might be other parts of LLVM that would benefit.

Actually all libs for which a -dev package is provided should be symbols-
versioned, *specially* if there is no API/ABI commitment.

So for what I do understand we need to patch the other linker scripts to add a 
version there, right?

I'll see to look at this later, but definitely not today. If someone beats me 
to it, the better.

-- 
Los chicos tienen un mayor dominio de la tecnología (y las habilidades y
lenguaje que eso implica) que los adultos con los que se relacionan. Por lo
general saben más que sus propios padres, sus docentes, sus pediatras,
psicólogos, que los políticos y funcionarios de sus comunidades. Eso afectó la
autoridad que tenía un adulto para habilitar al mundo.
  Luis Pescetti
  http://www.luispescetti.com/regale-su-obra/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 22 de enero de 2017 21:31:08 ART Rebecca N. Palmer wrote:
[snip]
> >> - Install and test LLVM 3.9 with stuff built with previous versions, like
> >> for example kdevelop ;-) Everything should just work.
> 
> kdevelop (#846410) has already been fixed by moving it to all-3.9; if
> you need a test case, I suggest the pocl-opencl-icd + blender one above.

They should keep crashing until they are rebuilt with a symbols-versioned 
version of the libs. What's needed to test here is the fact that stuff 
compiled against llvm without versioned symbols keeps working with versioned 
symbols (it should).

-- 
A child of five could understand this.
Fetch me a child of five.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 22 de enero de 2017 22:07:45 ART Sylvestre Ledru wrote:
> Le 22/01/2017 à 21:02, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > Control: tag -1 patch
> > 
> > I'm attaching a patch based on Rebecca's. I simply used a CMake variable
> > to
> > avoid harcoding a path. Note it's the patch itself and not a debdiff: you
> > need to add it to quilt's series file.
> 
> OK, you haven't pass the arg to LDFLAGS to make sure that libclang or
> liblldb get it,
> is that on purpose?

Actually I thought that that script was kind of global, but I might be wrong. 
I'm about to test this.
 
> > Sylvestre: if you can please try to build this one too. Once built there
> > are two things to test:
> > 
> > - Are the symbols versioned? For this creating a temporary symbols files
> > is
> > enough. Ping me if you don't know how to do this.
> 
> Just libclang is (the C lib).
> I haven't done it for the rest because it is C++ and not commitment
> from upstream on API stability  (on contraire)

Ah, I meant another thing. I normally use symbols files to check if symbols 
are versioned or not, I'm not talking about shipping them, just to check the 
patch worked as intended.



-- 
7: Hay diferencia entre "cortar" un archivo y "borrarlo" o "eliminarlo"
* Depende cuando se "cuelgue" Windows
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

On 22/01/17 21:07, Sylvestre Ledru wrote:
> , you haven't pass the arg to LDFLAGS to make sure that libclang or
> liblldb get it,
> is that on purpose?

My original intent was to avoid passing it to those parts of LLVM that
already use a "version" (actually which-symbols-are-public) script, as
I suspect having two version scripts is an error; you're right that
there might be other parts of LLVM that would benefit.

>> - Are the symbols versioned? For this creating a temporary symbols files is 
>> enough. Ping me if you don't know how to do this.
> Just libclang is (the C lib).
> I haven't done it for the rest because it is C++ and not commitment
> from upstream on API stability

The lack of API stability is exactly why we need symbol versioning
(otherwise we could just make everything use 3.9).  We're not proposing
to ship this .symbols file (which would be a compatibility statement),
just use it to check whether symbol versioning was successfully enabled.

>> - Install and test LLVM 3.9 with stuff built with previous versions, like 
>> for 
>> example kdevelop ;-) Everything should just work.

kdevelop (#846410) has already been fixed by moving it to all-3.9; if
you need a test case, I suggest the pocl-opencl-icd + blender one above.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 22/01/2017 à 21:02, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Control: tag -1 patch
>
> I'm attaching a patch based on Rebecca's. I simply used a CMake variable to 
> avoid harcoding a path. Note it's the patch itself and not a debdiff: you 
> need 
> to add it to quilt's series file.
OK, you haven't pass the arg to LDFLAGS to make sure that libclang or
liblldb get it,
is that on purpose?
> Sylvestre: if you can please try to build this one too. Once built there are 
> two things to test:
>
> - Are the symbols versioned? For this creating a temporary symbols files is 
> enough. Ping me if you don't know how to do this.
Just libclang is (the C lib).
I haven't done it for the rest because it is C++ and not commitment
from upstream on API stability  (on contraire)
> - Install and test LLVM 3.9 with stuff built with previous versions, like for 
> example kdevelop ;-) Everything should just work.
>
> Of course I'm also trying to do this myself but if you can try it yourself 
> the 
> better.
Thanks. Julien also mentioned that we should bump shlibs.

S




signature.asc
Description: OpenPGP digital signature

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 patch

I'm attaching a patch based on Rebecca's. I simply used a CMake variable to 
avoid harcoding a path. Note it's the patch itself and not a debdiff: you need 
to add it to quilt's series file.

I'm trying to get LLVM built into barriere.d.o. So far I've got to test 
failing but definitely due to non-related stuff, one due to a filesystem thing 
(maybe the host ran out of space for a moment?) and the other one due to lack 
of fakeroot on my side while running the tests, which I'm trying to re do now.

Sylvestre: if you can please try to build this one too. Once built there are 
two things to test:

- Are the symbols versioned? For this creating a temporary symbols files is 
enough. Ping me if you don't know how to do this.

- Install and test LLVM 3.9 with stuff built with previous versions, like for 
example kdevelop ;-) Everything should just work.

Of course I'm also trying to do this myself but if you can try it yourself the 
better.

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Description: add a simple linker script to version LLVM symbols
 This patch adds a very simple linker script to version the lib's symbols
 and thus trying to avoid crashes if an application loads two different
 LLVM versions (as long as they do not share data between them).
Author: Rebecca N. Palmer 
Author: Lisandro Damían Nicanor Pérez Meyer 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848368

---
 tools/llvm-shlib/CMakeLists.txt|2 +-
 tools/llvm-shlib/simple_version_script.map |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

Index: llvm-toolchain-3.9-3.9.1/tools/llvm-shlib/CMakeLists.txt
===
--- llvm-toolchain-3.9-3.9.1.orig/tools/llvm-shlib/CMakeLists.txt
+++ llvm-toolchain-3.9-3.9.1/tools/llvm-shlib/CMakeLists.txt
@@ -42,7 +42,7 @@ set_property(TARGET LLVM PROPERTY VERSIO
 list(REMOVE_DUPLICATES LIB_NAMES)
 if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux" OR "${CMAKE_SYSTEM_NAME}" STREQUAL "GNU" OR "${CMAKE_SYSTEM_NAME}" STREQUAL "kFreeBSD") # FIXME: It should be "GNU ld for elf"
   # GNU ld doesn't resolve symbols in the version script.
-  set(LIB_NAMES -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
+  set(LIB_NAMES -Wl,--version-script,${CMAKE_CURRENT_SOURCE_DIR}/simple_version_script.map -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
 elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
   set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
 endif()
Index: llvm-toolchain-3.9-3.9.1/tools/llvm-shlib/simple_version_script.map
===
--- /dev/null
+++ llvm-toolchain-3.9-3.9.1/tools/llvm-shlib/simple_version_script.map
@@ -0,0 +1 @@
+LLVM_3.9 { global: *; };


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Julien Cristau]

On Sat, Jan 21, 2017 at 09:52:58 +0100, Sylvestre Ledru wrote:

> I feel a bit uncomfortable to implement the ELF symbol versions that
> late in the cycle.
> Especially for two reasons: I don't know enough that stuff to evaluate
> and fix side effects
> it has always been like that without causing too much issue.
> 
> Can we lower the priority and I will fix that for the next stable release?
> 
I think that's a bad idea.

Cheers,
Julien

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Hello,

First, Rebecca, many thanks for the patch :)


Le 18/01/2017 à 19:54, Lisandro Damián Nicanor Pérez Meyer a écrit :
> On martes, 17 de enero de 2017 22:21:51 ART Rebecca N. Palmer wrote:
> [snip] 
>> This suggests the fix (warning: untested and not my area of expertise -
>> and if it is using that line, why is there no -Wl,--no-whole-archive in
>> the build log?):
> This part I don't know.
>
>> --- a/tools/llvm-shlib/CMakeLists.txt
>> +++ b/tools/llvm-shlib/CMakeLists.txt
>> @@ -42,7 +42,7 @@
>>   list(REMOVE_DUPLICATES LIB_NAMES)
>>   if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux" OR "${CMAKE_SYSTEM_NAME}"
>> STREQUAL "GNU" OR "${CMAKE_SYSTEM_NAME}" STREQUAL "kFreeBSD") # FIXME:
>> It should be "GNU ld for elf"
>> # GNU ld doesn't resolve symbols in the version script.
>> -  set(LIB_NAMES -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
>> +  set(LIB_NAMES
>> -Wl,--version-script,../../../tools/llvm-shlib/simple_version_script.map
>> -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
>>   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
>> set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
>>   endif()
>> --- a/dev/null
>> +++ b/simple_version_script.map
>> @@ -0,0 +1,1 @@
>> +LLVM_3.9 { global: *; };
> Probably the "../../../tools" path should be replaced by $
> {CMAKE_CURRENT_SOURCE_DIR}/tools


I think that we will have to replicate the change in
tools/llvm-shlib/CMakeLists.txt
for most (every?) library that llvm-toolchain ships as a matter of
consistency.

I feel a bit uncomfortable to implement the ELF symbol versions that
late in the cycle.
Especially for two reasons: I don't know enough that stuff to evaluate
and fix side effects
it has always been like that without causing too much issue.

Can we lower the priority and I will fix that for the next stable release?

Cheers,
S




signature.asc
Description: OpenPGP digital signature

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 17 de enero de 2017 22:21:51 ART Rebecca N. Palmer wrote:
[snip] 
> This suggests the fix (warning: untested and not my area of expertise -
> and if it is using that line, why is there no -Wl,--no-whole-archive in
> the build log?):

This part I don't know.

> --- a/tools/llvm-shlib/CMakeLists.txt
> +++ b/tools/llvm-shlib/CMakeLists.txt
> @@ -42,7 +42,7 @@
>   list(REMOVE_DUPLICATES LIB_NAMES)
>   if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux" OR "${CMAKE_SYSTEM_NAME}"
> STREQUAL "GNU" OR "${CMAKE_SYSTEM_NAME}" STREQUAL "kFreeBSD") # FIXME:
> It should be "GNU ld for elf"
> # GNU ld doesn't resolve symbols in the version script.
> -  set(LIB_NAMES -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
> +  set(LIB_NAMES
> -Wl,--version-script,../../../tools/llvm-shlib/simple_version_script.map
> -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
>   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
> set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
>   endif()
> --- a/dev/null
> +++ b/simple_version_script.map
> @@ -0,0 +1,1 @@
> +LLVM_3.9 { global: *; };

Probably the "../../../tools" path should be replaced by $
{CMAKE_CURRENT_SOURCE_DIR}/tools

> (Should also work with the obvious change for 3.8; I haven't checked
> 3.7.  Deliberately not making 3.9 "depend" on 3.8, as the whole point is
> to make the linker treat them as separate libraries)

Right.

> Some LLVM-using libraries use -Bsymbolic to avoid similar problems (e.g.
> #768185), but I don't know whether enabling that on LLVM itself would
> help: it may well be papering over a problem that symbol versioning
> would really solve.

Right.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Control: tags -1 patch

One way to reproduce this bug:
# apt-get install pocl-opencl-icd blender
$ gdb blender
open User Preferences -> System
This promptly crashes; beignet-opencl-icd 1.2.1-1 (LLVM 3.8, like pocl) 
also triggers it, but beignet-opencl-icd 1.2.1-2 and mesa-opencl-icd 
(LLVM 3.9, like the graphics part of mesa) don't.


#0  llvm::cl::Option::setArgStr(llvm::StringRef) ()
at /build/llvm-toolchain-3.9-3.9.1/include/llvm/ADT/SmallPtrSet.h:224
No locals.
#1  0x7fffbbe9aacb in llvm::cl::opt<(anonymous 
namespace)::HelpPrinter, true, llvm::cl::parser >::optllvm::cl::desc, llvm::cl::LocationClass<(anonymous 
namespace)::HelpPrinter>, llvm::cl::OptionHidden, 
llvm::cl::ValueExpected, llvm::cl::cat>(char const (&) [17], 
llvm::cl::desc const&, llvm::cl::LocationClass<(anonymous 
namespace)::HelpPrinter> const&, llvm::cl::OptionHidden const&, 
llvm::cl::ValueExpected const&, llvm::cl::cat const&) [clone 
.constprop.300] ()
at 
/build/llvm-toolchain-3.8-3.8.1/include/llvm/Support/CommandLine.h:1041

No locals.
#2  0x7fffbbe9ad08 in _GLOBAL__sub_I_CommandLine.cpp ()
at /build/llvm-toolchain-3.8-3.8.1/lib/Support/CommandLine.cpp:1661
No locals.
#3  0x77de95da in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#4  0x77de96eb in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#5  0x77dedc68 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#6  0x77de9484 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#7  0x77ded419 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#8  0x7fffee0f0ee9 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#9  0x77de9484 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#10 0x7fffee0f1521 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#11 0x7fffee0f0f82 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#12 0x7fffbf9f9212 in ?? () from 
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1

No symbol table info available.
#13 0x7fffbf9f9360 in ?? () from 
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1

No symbol table info available.
#14 0x7fffbf9f98d0 in ?? () from 
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1

No symbol table info available.
#15 0x7fffbf9fa0d3 in clGetPlatformIDs ()
   from /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
No symbol table info available.

The relevant lines of the LLVM build log appear to be

Scanning dependencies of target LLVM
make[4]: Leaving directory '/«PKGBUILDDIR»/build-llvm'
/usr/bin/make -f tools/llvm-shlib/CMakeFiles/LLVM.dir/build.make 
tools/llvm-shlib/CMakeFiles/LLVM.dir/build

make[4]: Entering directory '/«PKGBUILDDIR»/build-llvm'
[ 76%] Building CXX object 
tools/llvm-shlib/CMakeFiles/LLVM.dir/libllvm.cpp.o
cd /«PKGBUILDDIR»/build-llvm/tools/llvm-shlib && /usr/bin/g++-6 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I/«PKGBUILDDIR»/build-llvm/tools/llvm-shlib 
-I/«PKGBUILDDIR»/tools/llvm-shlib -I/«PKGBUILDDIR»/build-llvm/include 
-I/«PKGBUILDDIR»/include  -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold 
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG -fPIC-fno-exceptions -o 
CMakeFiles/LLVM.dir/libllvm.cpp.o -c 
/«PKGBUILDDIR»/tools/llvm-shlib/libllvm.cpp

[ 76%] Linking CXX shared library ../../lib/libLLVM-3.9.so
cd /«PKGBUILDDIR»/build-llvm/tools/llvm-shlib && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/LLVM.dir/link.txt --verbose=1
/usr/bin/g++-6  -fPIC -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC 
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG  -Wl,-O3 -Wl,--gc-sections -Wl,-z,relro 
-Wl,-z,defs -shared -Wl,-soname,libLLVM-3.9.so.1 -o 
../../lib/libLLVM-3.9.so.1 CMakeFiles/LLVM.dir/libllvm.cpp.o 
-Wl,-rpath,"\$ORIGIN/../lib" -Wl,--whole-archive [big list of 
../../lib/libLLVM(something).a libraries] -lrt -ldl -ltinfo -lpthread 
-lz -lm
cd /«PKGBUILDDIR»/build-llvm/tools/llvm-shlib && /usr/bin/cmake -E 
cmake_symlink_library ../../lib/libLLVM-3.9.so.1 
../../lib/libLLVM-3.9.so.1 ../../lib/libLLVM-3.9.so

make[4]: Leaving directory '/«PKGBUILDDIR»/build-llvm'
[ 76%] Built target LLVM

i.e. the main libLLVM shared library doesn't use a version script at 
all.  (Some of its other libraries do have "version scripts", but these 
are used for their other function of limiting which symbols are public, 

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

clone 848368 -1
reassign -1 llvm-toolchain-3.8
thanks

This should happen on all versions actually.

-- 
Trabaja como si no necesitaras el dinero.
Ama como si nunca hubieses sido herido.
Baila como si nadie estuviera mirando.
Canta como si nadie escuchara.
Vive como si fuera el Cielo en la Tierra.
  Anónimo

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Julien Cristau]

Control: severity -1 serious

On Fri, Dec 16, 2016 at 15:55:49 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:

> Source: llvm-toolchain-3.9
> Version: 1:3.9.1-1
> Severity: wishlist
> 
> As can be seen in #846410 having no ELF-versioned symbols leads to unexpected
> crashes when two LLVM versions are used in the same process.
> 
> Adding ELF symbols versions would allow avoiding this crashes as long as
> no data is interchanged between both versions of LLVM-related libs.
> 
For a library like LLVM with unstable ABI and multiple versions living
in the archive for extended periods of time (and even in releases), this
really isn't optional.

Cheers,
Julien

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 17 de diciembre de 2016 10:16:15 ART Sylvestre Ledru wrote:
> Le 16/12/2016 à 19:55, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > Source: llvm-toolchain-3.9
> > Version: 1:3.9.1-1
> > Severity: wishlist
> > 
> > As can be seen in #846410 having no ELF-versioned symbols leads to
> > unexpected crashes when two LLVM versions are used in the same process.
> > 
> > Adding ELF symbols versions would allow avoiding this crashes as long as
> > no data is interchanged between both versions of LLVM-related libs.
> 
> With the upcoming freeze, I won't probably do it to mitigate potential side
> effects...
> 
> But happy to have a look once we released Stretch.

That's totally cool.

I've been told that there is a command line to add a version to all symbols 
without a script, that should be enough at least for Debian packaging.

If I understand correctly LLVM is now using CMake, so I might even be able to 
provide you with a patch.

-- 
Tiempo para el tiempo y un rato mas.
  Profecías, Vox Dei, basado en Eclesiastes 3:1-9

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Sylvestre Ledru]

Le 16/12/2016 à 19:55, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Source: llvm-toolchain-3.9
> Version: 1:3.9.1-1
> Severity: wishlist
> 
> As can be seen in #846410 having no ELF-versioned symbols leads to unexpected
> crashes when two LLVM versions are used in the same process.
> 
> Adding ELF symbols versions would allow avoiding this crashes as long as
> no data is interchanged between both versions of LLVM-related libs.
With the upcoming freeze, I won't probably do it to mitigate potential side 
effects...

But happy to have a look once we released Stretch.

Sorry,
Sylvestre

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 16 de diciembre de 2016 15:55:49 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Source: llvm-toolchain-3.9
> Version: 1:3.9.1-1
> Severity: wishlist
> 
> As can be seen in #846410 having no ELF-versioned symbols leads to
> unexpected crashes when two LLVM versions are used in the same process.
> 
> Adding ELF symbols versions would allow avoiding this crashes as long as
> no data is interchanged between both versions of LLVM-related libs.

With ELF symbols I mean this:

https://sourceware.org/binutils/docs/ld/VERSION.html


-- 
~/ sweet ~/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

Source: llvm-toolchain-3.9
Version: 1:3.9.1-1
Severity: wishlist

As can be seen in #846410 having no ELF-versioned symbols leads to unexpected
crashes when two LLVM versions are used in the same process.

Adding ELF symbols versions would allow avoiding this crashes as long as
no data is interchanged between both versions of LLVM-related libs.

Thanks for considering, Lisandro.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'buildd-unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)