search for: soversion

...ime to test the >>>> branch and make sure everything works as expected. I'm going >>>> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the >>>> activity around the release calms down a little. >>>> >>> >>> The SOVERSION is still '7'. Maybe we should force it to '7.1' here? >>> >> >> It should already be changed. This is what I get when I build: >> >> [tstellar at llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME >> SONAME libLLVM-...

...works as expected. I'm going > > > > > > to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the > > > > > > activity around the release calms down a little. > > > > > > > > > > > > > > > > The SOVERSION is still '7'. Maybe we should force it to '7.1' here? > > > > > > > > > > > > > It should already be changed. This is what I get when I build: > > > > > > > > [tstellar at llvm llvm-build]$ objdump -p lib/libLLVM-7....

...version for the first time, please take some time to test the >> branch and make sure everything works as expected. I'm going >> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the >> activity around the release calms down a little. >> > > The SOVERSION is still '7'. Maybe we should force it to '7.1' here? > It should already be changed. This is what I get when I build: [tstellar at llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME SONAME libLLVM-7.1.so -Tom

...gt; > > > > to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the > > > > > > > > activity around the release calms down a little. > > > > > > > > > > > > > > > > > > > > > > The SOVERSION is still '7'. Maybe we should force it to '7.1' here? > > > > > > > > > > > > > > > > > > > It should already be changed. This is what I get when I build: > > > > > > > > > > > > [tstel...

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: DYLIB_LDFLAGS = -compatibility_version $(SOVERSION) -current_version $(VERSION) -Wl,-headerpad_max_insta...

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 libraries. Instead we include the version in the name of libLLVM, and we didn...

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 ,

...I had to either keep the >> major.minor .so versions (I believe because of the map files) or >> libvirt would fail to compile against the xen lib. > > I haven't looked at this but it sounds annoying. Though I would not 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 re...

...especially... ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX} ...is used. So, I fixed it up by pre-checking for... if(LLVM_VERSION_SUFFIX STREQUAL "git") Example (full patch attached): [ llvm/cmake/modules/AddLLVM.cmake ] @@ -541,11 +541,18 @@ function(llvm_add_library name) # Set SOVERSION on shared libraries that lack explicit SONAME # specifier, on *nix systems that are not Darwin. if(UNIX AND NOT APPLE AND NOT ARG_SONAME) - set_target_properties(${name} - PROPERTIES - # Since 4.0.0, the ABI version is indicated by the major version - SOVERSION $...

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 functionality between CMake and the autoconf build. >> >> In the autoconf build we didn't actually set the SOVERSION on libraries. Instead we include the version in the name of libLLVM, and we...

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

...ck look tells me only >> 5 out of 13 FLAC__metadata_object_vorbiscomment*() functions from >> FLAC/metadata.h exist in FLAC++'s VorbisComment class. >> >> Bas Timmer >> > This patch looks fine to me.. if applied we either need to raise the C++ > library SOVERSION and/or add a linker versioning script for *nix systems > though. Looks good to me to.? Erik, are you keeping up with patches?? Lately I've only been able to follow along. The soname is a good point: the flac release numbers are tied to the format and I rely on the sonames to manage binary...

...000000000 +0200 +++ llvm-project/llvm/cmake/modules/AddLLVM.cmake 2020-05-20 18:29:09.272548995 +0200 @@ -544,8 +544,8 @@ function(llvm_add_library name) set_target_properties(${name} PROPERTIES # Since 4.0.0, the ABI version is indicated by the major version - SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX} - VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}) + SOVERSION ${LLVM_VERSION_MAJOR} + VERSION ${LLVM_VERSION_MAJOR}) endif() endif() @@ -567,7 +567,7 @@ function(llvm_add_library name) if(${output_name} STREQUAL &...

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.

...ble, is nice, but should not stand in the way of the bug fixes > themselves. > > Some of the packagers should comment on this topic :) > > Breaking ABI in patch releases with no other changes? As a Debian packager (but not LLVM packager), I am opposed to changing ABI without bumping soversion and changing library name. If we have this: LLVM 3.4.0 => libclang-3.4.so.1 LLVM 3.4.1 => libclang-3.4.so.1 (same) but they are ABI-incompatible, that's going to cause trouble. But if we have this: LLVM 3.4.0 => libclang-3.4.so.1 LLVM 3.4.1 => libclang-3.4.so.2 (soname bumped)...

...cmake 2020-05-20 > > 18:29:09.272548995 +0200 > > @@ -544,8 +544,8 @@ function(llvm_add_library name) > > set_target_properties(${name} > > PROPERTIES > > # Since 4.0.0, the ABI version is indicated by the major version > > - SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX} > > - VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}) > > + SOVERSION ${LLVM_VERSION_MAJOR} > > + VERSION ${LLVM_VERSION_MAJOR}) > > endif() > > endif() > > > > @@ -567,7 +567,7 @...

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