Hi Ralf & Bob,
On 03/05/2010 19:58, Ralf Wildenhues wrote:
Hello,
* Matěj Týč wrote on Mon, May 03, 2010 at 05:45:26PM CEST:
If I have understood correctly, the whole LTversion stuff has only one
purpose - to inform users what have they installed.
Wrong. It provides a fairly porta
On 04/05/2010 20:41, Peter Rosin wrote:
Den 2010-05-04 20:00 skrev Ralf Wildenhues:
Errrm, is that really so? I tend to agree with Jef here...
I take it that your response is to my "... it will work" sentence, not
the paragraph below that.
Ah, indeed.
The algorithm *could* be interpreted su
On 11/04/2011 17:32, Sean Boudreau wrote:
Hi,
Here's a patch for qnx that I've been using for a while.
I'd like to try to get it integrated.
Regards,
-seanb
Does this patch work with non-gcc compilers for QNX, e.g. icc? Or does
one have to use qcc with such compilers? I've never tried
cross-
Hello,
I've just switched over to using libtool instead of using static
libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24.
The library builds fine under Linux, but won't link under Solaris Sparc
2.10.
/bin/bash ../../libtool --tag=CC --mode=link /opt/sfw/bin/gcc
-
Bad posting to my own posts so soon. But I've tried a few other systems
I have at hand.
Jason Curl wrote:
Hello,
I've just switched over to using libtool instead of using static
libraries. I've installed autoconf-2.61, automake-1.10 and
libtool-1.5.24.
The library builds f
Ralf Wildenhues wrote:
* Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST:
I've just switched over to using libtool instead of using static
libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24.
The library builds fine under Linux, but won't lin
Hello,
I've been testing my library now on various platforms and have come
across something else that I didn't expect.
I have a system that supports shared libraries (Solaris 9). As part of
some checks for 'getopt_long' I check if it exists in 'libiberty' if I
can't find it in the standard s
Bob Friesenhahn wrote:
On Fri, 17 Aug 2007, Jason Curl wrote:
I have a system that supports shared libraries (Solaris 9). As part
of some checks for 'getopt_long' I check if it exists in 'libiberty'
if I can't find it in the standard system. It's there in libi
Peter O'Gorman wrote:
On Fri, 2007-08-17 at 13:29 +0200, Jason Curl wrote:
As for testing the situation, AC_CHECK_LIB makes me believe it will
work. But it only works in a subset of cases (i.e. static only). I have
another implementation that I can compile in but at the moment there i
Ralf Wildenhues wrote:
Then this condition needs to be testable. I see two options:
- Automatically disable shared libraries on this platform
- Link statically from this library to our shared library
There are more options; see below. FWIW, I typically use notation
that's the other way ro
Hello,
I'm having some real problems with libtool getting it to link shared
libraries. I've created a very basic system that exhibits the same
problems I'm seeing. At the end is a brief overview of the configure.ac
and the Makefile.am's.
*** Cygwin: Detects shared/static but won't build.
$ ./c
Brian Dessent wrote:
Jason Curl wrote:
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info
0:0:0 -o libtp.la -rpath /usr/local/lib version.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
Libtool won't build shared libr
Brian Dessent wrote:
.dll.a is the import library. .dll is the actual library. Both should
be produced. The import library is used when linking against the
library, but it is not needed at runtime and contains no code. It's
typically distributed in the same context as headers -- it is needed
Hello,
Since migrating over to 'libtool' with automake to compile my packages,
on Solaris 9 and 10 we're now getting the new error:
ld.so.1: /home/user/myprog: fatal: libgcc_s.so.1: open failed: No such
file or directory
Killed
Before using libtool and using convenience libraries only, this
Ralf Wildenhues wrote:
* Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST:
I've just switched over to using libtool instead of using static
libraries. I've installed autoconf-2.61, automake-1.10 and libtool-1.5.24.
The library builds fine under Linux, but won't lin
Jason Curl wrote:
Ralf Wildenhues wrote:
* Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST:
I've just switched over to using libtool instead of using static
libraries. I've installed autoconf-2.61, automake-1.10 and
libtool-1.5.24.
The library builds fine under Linux,
Omri Azencot wrote:
Hello
I am using libtool 1.5.23 during the building process, I am also using
autoconf(2.61) to create the configure file.
in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got the
following line:
checking whether to build shared libraries... no
but, after
Omri Azencot wrote:
On 8/21/07, Jason Curl <[EMAIL PROTECTED]> wrote:
If you don't need to have the libraries installed for a convenience
library, use "noinst_*". See:
http://www.gnu.org/software/automake/manual/automake.html#A-Library
Similarly for libtool:
http:/
Hello,
Normally I write software for Posix like operating systems, but to assist
somebody I'm writing a Windows DLL that I'd like to later use the source for in
my Posix application without having to maintain two code bases.
I'm using
./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at"
Brian Dessent wrote:
Jason Curl wrote:
./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at"
--target=i586-pc-mingw32 --disable-static
on Cygwin to generate the Windows DLL
Target is not the right thing to use here. Target only has meaning in
the context of
Roumen Petrov wrote:
Jason Curl wrote:
Brian Dessent wrote:
Jason Curl wrote:
./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at"
--target=i586-pc-mingw32 --disable-static
on Cygwin to generate the Windows DLL
Target is not the right thing to use he
>
> > libtest.exe <-- Doesn't seem to work? No idea
> >what this is...
> > libtest
> > .libs/
> > libtest.exe<-- Will work when "libmofo-1.dll"
> >is in the path, e.g. copied to
> >this dir.
> >
> > Can any
Gary V. Vaughan wrote:
On 1 Feb 2008, at 01:06, Gary V. Vaughan wrote:
The Libtool Team is pleased to announce alpha
release 2.1b of GNU
Libtool.
With only one bug reported and fixed since Feb 1, either this is the
most spectacularly well engineered release in the history o
Hello,
To achieve my goals, I've borrowed some of the internals of the auto*
tools (and libtool). I'd like to somehow check the version of the
autotools during "autoreconf" time and include macros specific to a
particular version. If I see a version that I haven't tested with, then
I'd like t
Hello,
Recently some info was posted about using resource files with Windows
compilers. I'm trying to generate a reasonably simple Version resource and
there's some information I'm not sure how I can extract from the build process.
I'm using libtool-1.5.27a on MSYS-1.0.10 with MinGW-5.1.4.
Qu
Thanks Roumen, I've taken the same route as you've mentioned although
it's hackish.
I'm hoping someone from the libtool developer community can comment.
Roumen Petrov wrote:
Jason Curl wrote:
Hello,
Recently some info was posted about using resource files with Windows
c
Hello,
I was cross compiling libxml2, provided --prefix=/usr and make
DESTDIR=/opt/gcc-cross for a cross compiler (a different c-lib).
When testing, I noticed that I had to modify the "libxml2.la" file to change
the "libdir=/usr/lib" to "libdir=/opt/gcc-cross/usr/lib".
My question, is this cor
Roberto Bagnara wrote:
Hi there,
I have a project that builds several libraries. For most of them,
both the shared and static versions make sense, so I don't want
to use AC_DISABLE_STATIC. However, for some of them the static
version does not make any sense. How can I avoid the overhead
of b
Hello,
I can't move over to libtool 2.2.x just yet (most distros I support
still have 1.5.26 - sorry) and I'm generating libraries.
Is there any way, given an la file, to get the file name of the library
that will be generated at make time?
libtool --config gives me partial information (suc
Ralf Wildenhues wrote:
Hello Jason,
* Jason Curl wrote on Mon, Dec 08, 2008 at 08:43:35PM CET:
I can't move over to libtool 2.2.x just yet (most distros I support
still have 1.5.26 - sorry) and I'm generating libraries.
FWIW, most distros have a way to use upstream packag
Brian Dessent wrote:
Jason Curl wrote:
I can't move over to libtool 2.2.x just yet (most distros I support
still have 1.5.26 - sorry) and I'm generating libraries.
FWIW, most distros have a way to use upstream packages without
re-libtoolizing and re-autoreco
Hello,
I got some help with my previous question about library filenames but no
real answer, so I'm looking into what kind of effort it is to move over
to libtool 2.2.6a.
Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin
and I've come across my first problem. The old l
Ralf Wildenhues wrote:
Hello Jason,
* Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET:
Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin
and I've come across my first problem. The old libtool is removed
(1.5.27a) and the new is installed (a
Hello,
I've not heard an answer from my previous post and plunged into libtool
2.2.6a. To my surprise, except for one hitch, it works pretty well with
only some small changes to my macros.
I've still got the same problem with libtool 2.2.x, in that I still
can't determine a way to figure out
Hi Ralf
Ralf Wildenhues wrote:
Hello Jason,
* Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET:
Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin
and I've come across my first problem. The old libtool is removed
(1.5.27a) and the new is inst
I have a macro and in the first lines are:
AC_PREREQ(2.61)
LT_PREREQ([2.2.6])
When I run "autoreconf" I get:
$ autoreconf
configure.ac:33: error: m4_defn: undefined macro: _m4_divert_diversion
configure.ac:33: the top level
autom4te-2.63: /usr/bin/m4 failed with exit status: 1
aclocal-1.10: auto
Ralf Wildenhues wrote:
[ adding bug-autoconf ]
Hello Jason,
thanks for the bug report.
I always assume first a user error. I'm happy to be of assistance.
* Jason Curl wrote on Sat, Dec 13, 2008 at 10:01:22AM CET:
I have a macro and in the first lines are:
AC_PREREQ(2.61)
LT_P
Hello,
My next woe when porting over to libtool-2.x. It looks like the
compilation phase of libtool has changed for resources. The shared
library works, but the static library build on mingw32/cygwin no longer
works.
Not sure what I did to completely break it.
Hope somebody can help, the li
Ralf Wildenhues wrote:
* Jason Curl wrote on Sat, Dec 13, 2008 at 04:57:02PM CET:
/bin/sh ../../libtool --tag=RC --mode=compile windres rsrc.rc -o rsrc.lo
libtool: compile: windres rsrc.rc -o .libs/rsrc.o
libtool: compile: windres rsrc.rc >/dev/null 2>&1
The second
Bob Friesenhahn wrote:
On Sat, 13 Dec 2008, Jason Curl wrote:
My next woe when porting over to libtool-2.x. It looks like the
compilation phase of libtool has changed for resources. The shared
library works, but the static library build on mingw32/cygwin no
longer works.
If this is
I'm using libtool-2.2.6 on Cygwin and having some difficulties at the
end. I thought I had it working, but can't figure out what changed to
make it break.
In particular, my libtool library is compiling as shared, but when I
compile a test program to link to the shared library I get a failure
Alon Bar-Lev wrote:
On 12/13/08, Jason Curl wrote:
.rc.lo:
$(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=RC --mode=compile
$(RC) $(RCFLAGS) $< -o $@
libwin_la_LDFLAGS = -no-undefined -version-info @WINLIB_VERSION_INFO@
@SHLIB_VERSION_ARG@
You can look at Ope
Ralf Wildenhues wrote:
* Jason Curl wrote on Sat, Dec 13, 2008 at 06:00:31PM CET:
Ralf Wildenhues wrote:
* Jason Curl wrote on Sat, Dec 13, 2008 at 04:57:02PM CET:
/bin/sh ../../libtool --tag=RC --mode=compile windres rsrc.rc -o rsrc.lo
libtool: compile: windres rsrc.rc
Ralf Wildenhues wrote:
* Jason Curl wrote on Sat, Dec 13, 2008 at 07:47:43PM CET:
I'm using libtool-2.2.6 on Cygwin and having some difficulties at the
end. I thought I had it working, but can't figure out what changed to
make it break.
/.libs/lt-version.c: In func
Ralf Wildenhues wrote:
* Jason Curl wrote on Sat, Dec 13, 2008 at 09:05:52PM CET:
Ralf Wildenhues wrote:
I guess you're missing an
LT_LANG([Windows Resource])
I have a macro that calls this for me.
AC_DEFUN([LX_PROG_RC],
[AS_IF([test x$ac_cv_prog_ac_ct_R
Dan Nicholson wrote:
On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl wrote:
Ralf Wildenhues wrote:
Hello Jason,
* Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET:
Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin
and I've come
Roumen Petrov wrote:
Jason Curl wrote:
Dan Nicholson wrote:
On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl
wrote:
Ralf Wildenhues wrote:
[SNIP]
You're right, I only ran "autoreconf". "libtoolize" fixed the problem.
A concern I have about "libtoolize",
Tor Lillqvist wrote:
What exactly do you mean with "library version" ? Note that neither
the libtool triple current:revision:age nor the Linux-style suffix it
causes to be appended after the ".so" correspond to the actual version
number for most libraries.
Isn't it simplest to just pass a -DMYLI
Hello,
I've set up a library that can be built on Windows (mingw32 or cygwin)
or on a Unix type OS (e.g. Linux or Solaris). I've defined a header that
checks if the WINDOWS_H file exists and if it does, I then define things
like LIBAPI, WINAPI, DLLEXPORT.
That all works when I build a shared
t;.la" file that libtool knows
about.
Regards,
Jason.
Jason Curl wrote:
Hello,
I've set up a library that can be built on Windows (mingw32 or cygwin)
or on a Unix type OS (e.g. Linux or Solaris). I've defined a header that
checks if the WINDOWS_H file exists and if it d
50 matches
Mail list logo
