similar to: [LLVMdev] Name of the libraries + soname? 3.4.1 ?

On 12/05/2014 15:22, Tom Stellard wrote: > On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote: >> Hello, >> >> With the release of 3.4.1, the LLVM library has been renamed from >> libLLVM-3.4.so to libLLVM-3.4.1.so. In parallel, the soname has been >> updated to >> reflect this change. >> >> AFAIK, we kept the ABI compatible from 3.4

On 12/05/2014 16:13, Tom Stellard wrote: > On Mon, May 12, 2014 at 04:05:20PM +0200, Sylvestre Ledru wrote: >> On 12/05/2014 15:22, Tom Stellard wrote: >>> On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote: >>>> Hello, >>>> >>>> With the release of 3.4.1, the LLVM library has been renamed from >>>> libLLVM-3.4.so to

On 12/05/2014 17:12, Tom Stellard wrote: > On Mon, May 12, 2014 at 04:17:05PM +0200, Sylvestre Ledru wrote: >> On 12/05/2014 16:13, Tom Stellard wrote: >>> On Mon, May 12, 2014 at 04:05:20PM +0200, Sylvestre Ledru wrote: >>>> On 12/05/2014 15:22, Tom Stellard wrote: >>>>> On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote:

Hello, Lately, I have been working on moving Debian & Ubuntu packages to a stage2 build. This means that, instead of shipping llvm-toolchain packages built with gcc, we are rebuilding everything a second time using the newly built clang. Now, when pushed to Debian, it caused some unexpected issues in particular with rust reported here:

Hi, I would like to try again to do stable releases for LLVM 3.4. Even though we were unsuccessful with stable releases for LLVM 3.3, I learned some things going through the process, which I think will increase the chance for success with LLVM 3.4. So, here is my TODO list for a successful 3.4.1 release: 1. Get volunteers to help This is probably the most important thing on this list. Stable

On 02/05/2019 11:26 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >> On 02/05/2019 08:07 AM, Michał Górny wrote: >>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers >>> wrote: >>>> Hi, >>>> >>>> The release_70 branch is ready for the 7.1.0 release. I have updated the

On 02/05/2019 08:07 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers > wrote: >> Hi, >> >> The release_70 branch is ready for the 7.1.0 release. I have updated the >> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, >> which is the only bug we will be fixing in this release. >> >>

On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > On 02/05/2019 11:26 AM, Michał Górny wrote: > > > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: > > > > On 02/05/2019 08:07 AM, Michał Górny wrote: > > > > > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via

On Wed, 2019-02-06 at 14:09 -0800, Tom Stellard wrote: > On 02/05/2019 10:41 PM, Michał Górny wrote: > > On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > > > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > > > On 02/05/2019 11:26 AM, Michał Górny wrote: > > > > > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >

Tom (and Andy, Owen, Evan, Nadav), I'd like the following commits placed into the 3.4.1 branch. I've attempted to sort this list by code owner: Andrew Trick: r203719 - PR17473 r203725 - This test need the X86 backend, move it to the X86 sub directory. [adjusts the test location from r203719] r202273 - Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use.

Hello, all. I'm a fairly new maintainer of Gentoo packages for LLVM and clang. I'm trying to improve the way LLVM is built on Gentoo, and that's why I'm wondering which of the build systems of LLVM is supported better. As far as I'm aware, LLVM can be currently built using one of the two build systems: - one built on top of autoconf with custom Makefiles, - the other one

> On May 16, 2016, at 11:58 AM, Sylvestre Ledru <sylvestre at debian.org> wrote: > > Le 16/05/2016 à 19:19, Mehdi Amini a écrit : >> Hi, >> >> Anyone knows who is involved with this page on llvm.org? Which bot is updating it? (it seems stalled right now) > I am in charge of this. I had some recent issues with cmake but I think > I fixed them today. >

On 18/02/2015 23:29, Alexey Samsonov wrote: > > On Tue, Feb 17, 2015 at 6:23 PM, Anna Zaks <ganna at apple.com <mailto:ganna at apple.com>> wrote: > > >> On Feb 17, 2015, at 4:00 PM, Alexey Samsonov <vonosmas at gmail.com <mailto:vonosmas at gmail.com>> wrote: >> >> >> On Tue, Feb 17, 2015 at 3:37 PM, Anna Zaks <ganna at

Hi, I would like to begin the 3.4.2 release process for LLVM. There have been two issues identified in 3.4.1, which there is interest in having fixed in a 3.4.x release: 1. Build failure with gcc 4.9 (This is not a regression, 3.4 also fails to build with gcc 4.9). 2. Accidental change of libLLVM's DT_SONAME from libLLVM-3.4 libLLVM-3.4.1.so I will also accept any other bug-fixes that

Hello, Trying the 3.4.1 branch, I get following tests failing: LLVM :: CodeGen/X86/2009-06-05-VZextByteShort.ll LLVM :: CodeGen/X86/fma4-intrinsics-x86_64.ll LLVM :: CodeGen/X86/fp-fast.ll LLVM :: CodeGen/X86/vec_shift4.ll LLVM :: CodeGen/X86/vshift-4.ll I am testing on a Debian testing 64b. Does it ring a bell? Sylvestre

Hello, I don't know how it happened, but recent Ubuntu builds have broken -dev packages, which contain same libraries as non-dev packages. dpkg: error processing archive /var/cache/apt/archives/libllvm3.5_1%3a3.5~svn207603-1~exp1_amd64.deb (--unpack): trying to overwrite '/usr/lib/llvm-3.5/lib/libLLVM-3.5.so', which is also in package llvm-3.5-dev 1:3.5~svn207603-1~exp1 dpkg:

On 10/04/2014 16:32, Tom Stellard wrote: > On Wed, Apr 09, 2014 at 06:47:19PM +0200, Sylvestre Ledru wrote: >> Hello, >> >> Trying the 3.4.1 branch, I get following tests failing: >> LLVM :: CodeGen/X86/2009-06-05-VZextByteShort.ll >> LLVM :: CodeGen/X86/fma4-intrinsics-x86_64.ll >> LLVM :: CodeGen/X86/fp-fast.ll >> LLVM ::

What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/

Hello Dirk, Dirk Eddelbuettel <edd at debian.org> writes: > On 20 November 2016 at 19:28, Joseph Mingrone wrote: > | Hello, > | > | R's shared libraries are linked without setting the soname. This is causing problems for some consumers. > | > | Error: /usr/local/lib/R/library/tseries/libs/tseries.so is linked to > |

Hello, R's shared libraries are linked without setting the soname. This is causing problems for some consumers. Error: /usr/local/lib/R/library/tseries/libs/tseries.so is linked to /usr/local/lib/R/lib/libRblas.so which does not have a SONAME. math/R needs to be fixed. What's the correct way to add the necessary linker flags? I believe it should be something