2022 at 8:02 PM Mike Frysinger wrote:
>
> On 06 Feb 2022 11:56, Daniel Herring wrote:
> > FWIW, libtool is a particularly difficult code base to release. Long
> > history, many users, multi-platform, ...
> >
> > I would personally reco
FWIW, libtool is a particularly difficult code base to release. Long
history, many users, multi-platform, ...
I would personally recommend the "slow" process unless you are confident
this release will "do no harm". It was made for a reason, even if it
feels nobody is participating. Relax,
On Sun, 4 Aug 2013, John Vonachen wrote:
/bin/bash ../libtool --tag=CC --mode=link gcc -O20 -Wall -ffast-math
-fsigned-char -g -O2 -no-undefined -version-info 8:1:8 -o libogg.la -rpath
/usr/local/lib framing.lo bitwise.lo
../libtool: eval: line 6444: unexpected EOF while looking for
The only sure way I know to statically link a single library is to
dispense with the common -lname and directly specify /path/to/libffcall.a
(or the platform-specific equivalent) on the linker command line.
- Daniel
___
On Thu, 21 Jul 2011, L A wrote:
I am trying to cross compile a library on a linux machine. The
libstdc++.a that comes with the toolchain is not compiled with fPIC
and it is binary only. I would like to use the so file instead.
However libtool keeps linking libstdc++.a (as whole-archive) and I
On Wed, 19 May 2010, Adam Mercer wrote:
double calculate_ligo_snr_from_strain(
REAL4TimeVectorSeries *strain,
SimInspiralTable *thisInj,
char ifo[3]);
has changed to:
double calculate_ligo_snr_from_strain(
REAL4TimeVectorSeries *strain,
SimInspiralTable *thisInj,
const char ifo[3]);
On Sun, 21 Mar 2010, Ersin Akinci wrote:
I've been trying to build DirectFB, and I think that I've narrowed down a bug
in the build process to what might be a confusing
make or libtool behavior. I've been cross-compiling using --sysroot for gcc so
that everything will link against a custom
On Wed, 12 Aug 2009, Michel Briand wrote:
Please give me the way to learn those ABI number you cite.
I've looked into many OSS and found in Makefile.am only 2 cases :
- version-info 1:0:0 (the guys there didn't want to bother with
libtool versioning apparently... ;))
- version-info with the
On Tue, 4 Nov 2008, Ralf Wildenhues wrote:
* Daniel Herring wrote on Tue, Nov 04, 2008 at 07:13:23AM CET:
I would like to build and install several revisions of a large system
(hours to compile on slower machines).
My hope was to build the project in a central location so unchanged files
I would like to build and install several revisions of a large system
(hours to compile on slower machines).
My hope was to build the project in a central location so unchanged files
wouldn't need to recompile, and then have libtool relink everything and
fix the RPATHs during install. This
On Tue, 4 Mar 2008, Dan Nicholson - [EMAIL PROTECTED] wrote:
Do you know if there's any way for automake to ignore the include
keyword? I.e., I really want the include to be processed by make,
not automake. The only ugly way I could think of was to include a
dummy file that had the real
On Mon, 3 Mar 2008, Peter O'Gorman - [EMAIL PROTECTED] wrote:
I am pretty sure that you can similarly avoid the need for a fake
convenience .la, but can not work it out without actually attempting a
build :)
On a related note, I'm working with a non-libtool library (we'll call it
x) that
On Mon, 12 Nov 2007, Brendon Costa wrote:
I can see the call of the destructor method working correctly in all
cases. As you said it is just a virtual function call. However i was
wondering if the memory de-allocation is performed by the child or the
caller.
In general, memory management done
On Thu, 8 Nov 2007, Peter O'Gorman wrote:
[EMAIL PROTECTED] wrote:
I'm trying to link to a library that uses different names for the static
and shared versions.
Example: libABC.so and libABCz.a
Can someone suggest a way to express this to libtool? Just passing -lABC
fails for static links;
14 matches
Mail list logo
