search for: soversions

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 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 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 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: >

There is a linker argument that only Apple's GCC recognizes in the latest build. In libs/wine/Makefile.in, there is a variable that reads: Code: DYLIB_LDFLAGS = -compatibility_version $(SOVERSION) -current_version $(VERSION) -headerpad_max_install_names in order for non-Apple GCC to successfully build, it needs to pass-through the argument to the linker. The line should read: Code:

Hi, On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: > Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match functionality between CMake and the autoconf build. > > In the autoconf build we didn't actually set the SOVERSION on

Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote: > I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome. This seems to be due to your commit http://reviews.llvm.org/D13841 ,

...say I am very proficient in this area, it feels like the soversioning and map files are moves into a better direction. The existing ones which get renamed and drop the soversion were just using the Xen version for that, regardless of what functions were kept or changed. The new ones seem to go for soversions that change only when the api changes. So having the rename plus keeping the soversion of the new libs felt like the best compromise. The renaming allows to have multiple versions of libxen installed. Which became more problematic with libxl. Not when only the xen toolstack is used, but with other...

[ Please CC me I ma not subcribed to this mailing-list ] [ CC Tom and Hans as LLVM/stable maintainers ] Hi, I want to understand the version handling in LLVM/Clang/LLD. Normally, I build from "release/10.x" Git branch by using the tool tc-build from ClangBuiltLinux project. With "llvm-10.0.1-rc1" Git tag I was able to setup a llvm-toolchain consisting of the projects

On 31.08.2016 10:43, Stefan Bader wrote: > On 30.08.2016 18:56, Ian Jackson wrote: >> Hi. I've been looking at the BTS and PTS and security tracker, and it >> looks like maybe you could do with some help ? >> >> Issues I noticed include: >> >> * 4.7, the latest Xen upstream release, is not in sid > > If it is of any help, I did some initial work

On Wed, Jan 27, 2016 at 3:18 AM, Ismail Donmez via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: >> Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match

The attached patch adds the missing FLAC__metadata_object_seektable_*() functions from FLAC's metadata object methods (FLAC/metadata.h) to FLAC++'s SeekTable class. Of the 11 functions in the C API, only 4 are currently in the C++ API, this patch adds the missing 7. If this patch is ok, VorbisComment will be next. A quick look tells me only 5 out of 13

> From: Cristian Rodr?guez <crrodriguez at opensuse.org> > Sent: Sunday, May 6, 2012 8:24 AM > > El 05/05/12 02:23, Bastiaan Timmer escribi?: >> The attached patch adds the missing FLAC__metadata_object_seektable_*() >> functions from FLAC's metadata object methods (FLAC/metadata.h) to >> FLAC++'s SeekTable class. Of the 11 functions in the C API,

On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/19/2020 09:05 PM, Sedat Dilek wrote: > > Hi Tom, > > > > thanks and congrats for LLVM 10.0.1-rc1 release. > > > > [1] shows 2 assets. > > 10.0.0 RCs had a lot of more assets. > > I am missing the llvm-project-10.0.1rc1.tar.xz tarball. > > > > Will

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. Since this is an ABI breaking changing and also we are introducing a minor version for the first time, please take some time to test the branch and make sure everything works as expected.

On Thu, Dec 19, 2013 at 8:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > the other thing we need to determine is > > > > whether or not we want to maintain a stable ABI for the bugfix > > > > releases. > > > > With 3.3, the plan was to have a stable ABI, but this caused me > > > > to reject several fixes. I would recommend

On Wed, May 20, 2020 at 11:12 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/20/2020 09:53 AM, Sedat Dilek wrote: > > On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > >> > >> On 05/19/2020 09:05 PM, Sedat Dilek wrote: > >>> Hi Tom, > >>> > >>> thanks and congrats for LLVM

----- Original Message ----- > From: "Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" <ofv at wanadoo.es> > Sent: Wednesday, December 18, 2013 11:07:23 AM > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > On Wed, Dec

Hi Tom, thanks and congrats for LLVM 10.0.1-rc1 release. [1] shows 2 assets. 10.0.0 RCs had a lot of more assets. I am missing the llvm-project-10.0.1rc1.tar.xz tarball. Will you provide them later or is there a new development/workflow decision I do not know of? BTW, the source zip and tar.gz tarballs show no sizes. I am using Mobile LTE/UMTS to download stuff from the Internet. For now I

Fix the soversion to 3.1.0. CVS tag: libXfixes-4_0_1 http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.1.tar.gz 6cdee1e7023720b8317a3dc545d22849 libXfixes-4.0.1.tar.gz 60d18de658027f2377f0e110445ea60f8551bf94 libXfixes-4.0.1.tar.gz http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.1.tar.bz2 c20eba4be3e8379fd774e999b65d3f90 libXfixes-4.0.1.tar.bz2