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-
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
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
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
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
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
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",
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
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
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 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
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
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
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
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
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:
[ 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
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
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
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
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 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
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
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
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
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 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
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,
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
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
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
>
> > 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
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
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
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"
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:/
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
-
50 matches
Mail list logo