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
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
+++
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
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
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
>
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
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
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
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,
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).
>
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
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
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.
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
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
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
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
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,
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
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
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
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.
> ---
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,
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.
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
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
> >
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
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
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
29 matches
Mail list logo