When to bump library api version (current)

Hi We are coming up for a new release of one of the libraries I maintain and I'm not sure whether the library api version needs bumping (specifically current). The only API change is that the function below: double calculate_ligo_snr_from_strain( REAL4TimeVectorSeries *strain, SimInspiralTabl

Re: When to bump library api version (current)

On Wed, May 19, 2010 at 23:36, Daniel Herring wrote: Daniel > ISTM that this is not an ABI change; the addition of const only affects the > code being called, and in a manner compatible with the non-const version > (assuming calling code did not expect this parameter to be changed). This was my

Re: When to bump library api version (current)

On Thu, May 20, 2010 at 13:37, Ralf Wildenhues wrote: > For what it's worth, I wouldn't treat this as an incompatible API bump. > I would mention it to my users though, because when they use function > pointers and assign your library function, the change will show up. Thanks for the clarificati

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Thu, May 20, 2010 at 19:22, Gary V. Vaughan wrote: Hi > The Libtool Team is pleased to announce release candidate 2.2.7b of GNU > Libtool.  If there are no serious deficiencies reported in this release, > it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix > any problems and

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Fri, May 21, 2010 at 14:01, Gary V. Vaughan wrote: Gary > In the end AC_PROG_CXX is not very time consuming, so I'd recommend > something more along the lines of (untested - from memory): > > AC_PROG_CXX > AM_CONDITIONAL([BUILD_BOINC], [test "x${boinc}" = xtrue]) > > and then in Makefile.am >

Re: GNU Libtool 2.2.8 released (stable)

On Fri, Jun 4, 2010 at 15:44, Gary V. Vaughan wrote: Hi >  - Initial support for the Cuda Compiler Driver on GNU/Linux. Is there any documentation for this anywhere, I can't find anything in the online manual nor info document and a quick Google search only leads me to the release notes for 2.2

libtool and Cuda

On Tue, Aug 31, 2010 at 14:12, Ralf Wildenhues wrote: >> Is there any documentation for this anywhere, I can't find anything in >> the online manual nor info document and a quick Google search only >> leads me to the release notes for 2.2.8? > > Well, the support is basically >

Re: libtool and Cuda

On Wed, Sep 1, 2010 at 13:44, Ralf Wildenhues wrote: Ralf > Do you know how?  (Because that knowledge will be needed when > implementing this.) Not yet, a new programmer has just been employed by a group in our collaboration to work on this. He's got a few ideas but needs to get up to speed wit

potential linking issue with Xcode-4.2 on Lion

Hi I testing some software I maintain using the recently release Xcode-4.2 on Mac OS X 10.7.2, and am running into the follow error during link: /bin/sh ../../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -g3 -O4 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wpointer-ari

Re: potential linking issue with Xcode-4.2 on Lion

On Mon, Oct 17, 2011 at 16:40, Peter O'Gorman wrote: Peter > Does it work if you remove -mmacosx-version-min=10.4? That resulted in the same error, but your idea led me to remove each flag one by one and it turns out that the insane optimization level that was being used is the culprit. Removin

Re: potential linking issue with Xcode-4.2 on Lion

On Mon, Oct 17, 2011 at 17:07, Peter O'Gorman wrote: > Great, please file a radar with apple for it. Filed. #10299475 Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool

linking problems on SL6

Hi In building a development snapshot of one of my projects, to a custom path, on SL6 I am running into what appears to be a linking problem. The libtool command used to link the library is as follows: libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/Aggregation.o .libs/FrameCache.o .libs

Re: linking problems on SL6

On Mon, Nov 21, 2011 at 12:21, Peter O'Gorman wrote: Peter > Are these -Wl,-rpath flags coming from libtool? They seem to be there > already on the libtool command line. Could you post this snippet of your > makefile.am, please? I am not setting these myself and they don't seem to be coming fro

Re: linking problems on SL6

On Mon, Nov 21, 2011 at 15:39, Peter O'Gorman wrote: > Glad it works around it. The problem is libtool brokenness, most vendors > patch around it in their packaged libtool, e.g. > > http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28

Re: linking problems on SL6

On Wed, Nov 23, 2011 at 08:52, Peter O'Gorman wrote: > I'm not sure if we ever looked for what distros use what layout for > multilibs, and how to detect them. > > There was a patch somewere which was slow, but ended up correct, using > ldconfig. I'll look for it again. Thanks, let me know if I

Re: Libtool, rpath, and libGL.so

On Mon, Nov 28, 2011 at 23:30, Andy Spencer wrote: > This seems to be caused by libtool adding a -rpath flag which forces the > application to use the /usr/lib64 version provided by mesa even though > ld.so.conf has been properly configured to use the nvidia version. I ran into essentially the s

Re: Libtool, rpath, and libGL.so

On Wed, Dec 7, 2011 at 23:26, Peter O'Gorman wrote: > Does anyone want to try again? > > http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html > > I only have red hat like distros, so if someone could update the patch and > look at other distros that'd be great. I can have a pl

shared library version info query

Hi I am in the process if rewriting the build system for a project I've been working on and am noticing strange behaviour with the shared library version info, I have the following in my projects configure.ac for setting the shared library version info: # set library api info AC_SUBST([LIBAPI], [

Re: shared library version info query

On Thu, May 7, 2009 at 23:09, Adam Mercer wrote: > If I understanding the versioning correctly, shouldn't there also be a > libFrame.1.0.0.dylib? Is there anything I'm missing, or not > understanding? It appears that I wasn't understanding this correctly as on Da

condor_compile and libtool

Hi Does anyone have any experience with libtool based projects and condor_compile (for the Condor workflow management system )? I would like to update the libtool in one of our projects to the latest 2.2.6a release but I am running into strange problems when compil

Re: condor_compile and libtool

On Mon, May 11, 2009 at 01:08, Ralf Wildenhues wrote: >> config.status: creating Makefile >> sed: file ./confstatiT3775/subs-2.sed line 40: unterminated `s' command >> >> and the resulting Makefile is empty. This is the only error and the >> project builds and links fine when not compiling for co

Re: condor_compile and libtool

On Mon, May 11, 2009 at 16:36, Ralf Wildenhues wrote: > * Adam Mercer wrote on Mon, May 11, 2009 at 08:11:05PM CEST: >> This is building on CentOS5, which comes with autoconf-2.59, I built a >> distribution on my laptop which has autoconf-2.63 and then configure >> worked,

Re: condor_compile and libtool

On Wed, May 13, 2009 at 13:32, Ralf Wildenhues wrote: > What I can gather about Condor on GNU/Linux is that it used to support > static libraries only, cf. this old manual: > . > > So you might want to try >  ./configure --ena

Re: Damien Lespiau » shave: making the auto tools output sane

On Tue, Jun 9, 2009 at 19:25, Bob Friesenhahn wrote: > Is this some sort of Automake 1.11 look-alike?  Why do this if Automake does > it already?  Time to wake up and smell the coffee ... Wow, I didn't realise automake could do this. How is it configured? I must not be googling properly as I can'

Re: Damien Lespiau » shave: making the auto tools output sane

On Tue, Jun 9, 2009 at 20:51, Adam Mercer wrote: > Wow, I didn't realise automake could do this. How is it configured? I > must not be googling properly as I can't find anything. Never mind, found it. Cheers Adam ___ http://lists

Re: Damien Lespiau » shave: making the auto tools output sane

On Wed, Jun 10, 2009 at 00:25, Vincent Torri wrote: > Is it possible to add AM_SILENT_RULES only when automake version is >= 1.11, > that is is there a good way to retrieve the version of automake in > configure.ac ? Something like: > > AM_INIT_AUTOMAKE(1.6 dist-bzip2) > if test $AUTOMAKE_CURRENT_

segfault on library linking

Hi Recently I've started seeing messages of the following form when linking my library on Mac OS X: ../../../libtool: line 7824: 39012 Segmentation fault dsymutil .libs/liblalmetaio.0.dylib although it appears that the library is successfully linked, from the dsymutil man page it seems like

Re: segfault on library linking

On Fri, Aug 28, 2009 at 01:34, Mike Frysinger wrote: > this crash isnt coming from libtool.  you should ask on one of the apple/os x > forums about it. Thanks, I will Cheers Adam ___ http://lists.gnu.org/mailman/listinfo/libtool

revisiting condor and libtool

Hi A while ago I posted a question regarding problems I was having with updating a project, that is built for the condor workflow management system (http://www.cs.wisc.edu/condor/), to the latest version of libtool: unfortunately

Re: revisiting condor and libtool

On Tue, Dec 1, 2009 at 00:26, Ralf Wildenhues wrote: > Yes, the condor_compile script puts the quotes all in the wrong places. > To work around it, use AC_CONFIG_HEADERS([config.h]) and include that > from your code.  Your build setup looks ok otherwise. Thought so. > Below's a completely untes

Re: revisiting condor and libtool

On Tue, Dec 1, 2009 at 00:26, Ralf Wildenhues wrote: > Yes, the condor_compile script puts the quotes all in the wrong places. > To work around it, use AC_CONFIG_HEADERS([config.h]) and include that > from your code.  Your build setup looks ok otherwise. Thanks, using AC_CONFIG_HEADERS results i

Re: revisiting condor and libtool

On Tue, Dec 1, 2009 at 12:54, Ralf Wildenhues wrote: Ralf > please trim stuff that you don't refer to from replies, thanks. Sorry, I usually do but forgot last time. > BTW, you should usually include config.h as very first header, > because it can influence the behavior of system headers. goo

Re: revisiting condor and libtool

On Tue, Dec 1, 2009 at 14:45, Ralf Wildenhues wrote: Ralf > As developer, add it to AM_LDFLAGS.  You can AC_SUBST([AM_LDFLAGS]) from > configure.ac if you need it in multiple Makefile.am files.  Note that > target_LDFLAGS override AM_LDFLAGS unless you add the latter to the > former. Fantastic,

autoreconf always calling libtool with --copy option on Ubuntu 9.10

Hi I'm running into a strange problem with libtool when running autoreconf on one of my projects under Ubuntu 9.10. autoreconf always seem to run libtoolize with the copy option, even though there in no need for it to: $ autoreconf -v autoreconf: Entering directory `.' autoreconf: configure.ac: n

Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10

cd /us On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini wrote: >> I only have this problem with Ubuntu 9.10, does anyone know what could >> be causing this? > > What is the output of autoreconf --version? It reports itself as 2.64 > Can you attach your > /usr/bin/autoreconf so that we can look for

Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10

On Tue, Dec 15, 2009 at 02:31, Paolo Bonzini wrote: > It's an Ubuntu-specific (maybe Debian-specific) patch. Thanks I'll follow this up with them. Cheers Adam ___ http://lists.gnu.org/mailman/listinfo/libtool

use of -flat_namespace on darwin

Hi In one of our projects we are experiencing a problem which seems to be related to the fact that the -flat_namespace option is not being passed to the linker, looking into why this is the case I see the following code in libtool.m4: case $host_os in rhapsody* | darwin1.[[012]]) _l

Re: use of -flat_namespace on darwin

On Wed, Dec 23, 2009 at 16:30, Peter O'Gorman wrote: >> In one of our projects we are experiencing a problem which seems to be >> related to the fact that the -flat_namespace option is not being >> passed to the linker, looking into why this is the case I see the >> following code in libtool.m4: