I am currently porting a largish piece of software from Linux to
Windows, and I'm having trouble compiling some of the third-party
libraries it requires.
(before you ask: yes, I have to compile most of these libraries myself;
this is not the issue here.)
I realize that this comes up regularly, bu
We are pleased to announce the release of GNU Libtool 2.2.6b.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, port
So, I screwed up ...
Yes, I know it's not best. I tagged 2.2.6b yesterday, and moved the tag
this morning, so you may have the tag pointing at the wrong commit.
Sorry,
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listin
Congrats on the release!
I'm a little confused by the version number, though.
2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This
was also the rationale provided as to why the "a" suffix was not
included in the directory name from the expanded tarball. This new
release has
On 11/16/2009 09:18 AM, Jeff Squyres wrote:
Congrats on the release!
I'm a little confused by the version number, though.
2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was
also the rationale provided as to why the "a" suffix was not included in
the directory name from the e
On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote:
We are intending to release 2.2.8 sometime (hopefully soon) with all
the new features and lots of bug fixes from git HEAD.
So why not call this release 2.2.8 and bump the version number of the
next one to 2.2.10? Is it technically difficul
On 11/16/2009 09:32 AM, Jeff Squyres wrote:
On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote:
We are intending to release 2.2.8 sometime (hopefully soon) with all
the new features and lots of bug fixes from git HEAD.
So why not call this release 2.2.8 and bump the version number of the
next
If you happen to be stuck using an older libltdl for some reason, the
attached untested patch should give you the same changes in behavior as
the badly numbered 2.2.6b release.
Peter
--
Peter O'Gorman
http://pogma.com
diff -urN libtool-1.5.26.orig/libltdl/ltdl.c libtool-1.5.26/libltdl/ltdl.c
--
On Mon, 16 Nov 2009, Jeff Squyres wrote:
Congrats on the release!
I'm a little confused by the version number, though.
2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also
the rationale provided as to why the "a" suffix was not included in the
directory name from the
Hi,
For some reason our release procedure calls for running make distcheck 5
times. This is a tad onerous (one make distcheck takes almost an hour on
my system).
HACKING asks for:
* Run `make distcheck'
and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'
and `make distch
For some reason our release procedure calls for running make distcheck 5
times. This is a tad onerous (one make distcheck takes almost an hour on my
system).
HACKING asks for:
and `make distcheck CC=g++'
I think keeping CC=g++ might be a good idea because many users (self
included) use libl
On 11/16/2009 11:29 AM, David Fang wrote:
For some reason our release procedure calls for running make distcheck
5 times. This is a tad onerous (one make distcheck takes almost an
hour on my system).
HACKING asks for:
and `make distcheck CC=g++'
I think keeping CC=g++ might be a good idea beca
On Mon, 16 Nov 2009, Dag-Erling Smørgrav wrote:
Second question: there is no libstdc++.dll.a; is this a mistake on the
part of the MinGW maintainers?
I suggest that you look into the issue of throwing C++ exceptions past
DLL boundaries. This seems to be a complex issue for Windows with
seve
On Mon, 16 Nov 2009, Dag-Erling Smørgrav wrote:
Fifth question: can someone give a concise explanation of what, exactly,
-no-undefined does, and why it is required?
This option is an indication that the application is fully prepared to
resolve all symbols at link time. One requirement for th
Hi Peter,
* Peter O'Gorman wrote on Mon, Nov 16, 2009 at 05:16:15PM CET:
> For some reason our release procedure calls for running make
> distcheck 5 times. This is a tad onerous
Agreed.
> (one make distcheck takes almost an hour on my system).
Hmpf. If you have a multi-way system, try e.g.
15 matches
Mail list logo
