Hello,
I've recently noticed that libtool (2.4, as included in Cygwin 1.7) could
decide to create a static library instead of a shared one it was asked to
create if it couldn't do the latter. Here is an example of a message where
libtool explains why it does it itself:
... during libxml
On Thu, 16 Jun 2011 15:36:24 -0500 (CDT) Bob Friesenhahn
wrote:
BF> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF> > different functions (_foo vs imp_foo). So IMO creating a static library
BF> > when libtool was requested to build a DLL is never the right thing to do
BF> &g
On Thu, 16 Jun 2011 18:15:01 -0500 (CDT) Bob Friesenhahn
wrote:
BF> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF> > BF>
BF> > BF> In what way was libtool specifically requested to build a DLL?
BF> >
BF> > I'm not sure about the details (please keep i
On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn
wrote:
BF> On Fri, 17 Jun 2011, Vadim Zeitlin wrote:
BF> >
BF> > Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just
BF> > too accustomed to the "traditional" Windows way and have
Charles Wilson cwilson.fastmail.fm> writes:
> > A more interesting question is if the current situation with libtool can
> > be improved because I continue to believe that getting a static library
> > when you're trying to build a shared one can be very unexpected. And this
> > can be the case e
Hello,
I'm using libtool 2.4 under Cygwin 1.7 to build a project using
i686-w64-mingw32-g++ 4.5.3 cross-compiler. This mostly works just fine (in
particular, it's a real relief to not have to worry about the identity
mounts and paths compatibility between MinGW and Cygwin) but I get an error
at
Charles Wilson cwilson.fastmail.fm> writes:
> On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
> > Charles Wilson writes:
> >> No, I think --disable-static, if specified, should actually *disable
> >> static*. That should be sufficient.
> >>
> >
Vadim Zeitlin zeitlins.org> writes:
> And as this project build options also include "-std=c++0x",
> __STRICT_ANSI__ is defined. For the compiler I use it would be enough to
> add _CRTIMP in front of the declaration as this is how _putenv() is really
> declared in /usr/
On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin wrote:
PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
PR> > I have no idea whether -no-undefined is supposed to work like this but in
PR> > any case it seems to me that it's perfectly useless right now. It's not
PR> &
On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn
wrote:
BF> On Thu, 23 Jun 2011, Vadim Zeitlin wrote:
BF> >
BF> > I.e. it created a shared library with undefined symbols without any
BF> > problems because it never actually passed -no-undefined to g++/ld.
BF>
BF
Charles Wilson cwilson.fastmail.fm> writes:
> No, what it means is that, IF the project maintainers want to support
> shared libraries (DLLs) on win32, then they must do the following -- and
> this is true regardless of whether libtool is involved.
I think the real problem is that we differ in
On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin wrote:
PR> Den 2011-06-23 14:25 skrev Vadim Zeitlin:
PR> > Am I the only one to think that this behaviour is singularly
PR> > unhelpful?
PR>
PR> Of course not, others have stated that a patch would be welcome to
PR> f
Hello,
I'd like to create Windows binaries for my software from Linux, which
includes creating a couple of DLLs and EXEs that use them. This is not too
difficult to do with just manual makefiles as both the cross-compiler and
linker work just fine. Libtool is another matter entirely however:
1.
On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote:
NB> On 2/9/16, Vadim Zeitlin wrote:
NB> > I'd like to create Windows binaries for my software from Linux, which
NB> > includes creating a couple of DLLs and EXEs that use them. This is not too
NB> > difficult to do
On Tue, 9 Feb 2016 21:18:42 -0600 (CST) Bob Friesenhahn
wrote:
BF> On Tue, 9 Feb 2016, Vadim Zeitlin wrote:
BF> >
BF> > 2. Enabling this option is not enough as you must also painstakingly add
BF> > -no-undefined to all LDFLAGS. Why does libtool need to force you to do
On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn
wrote:
BF> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
BF> >
BF> > Sorry but this is just not true for the MSW DLLs. If the libtool user
BF> > tries to build a DLL, you can safely assume that it will not have
un
On Wed, 10 Feb 2016 10:02:25 +0100 Peter Rosin wrote:
PR> You appear confused (as almost everybody else) about what -no-undefined
PR> means to libtool. The confusion stems from(?) the similarly named linker
PR> option, --no-undefined, which apparently does what people expect from
PR> the libtool
On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler wrote:
NB> On 2/9/16, Vadim Zeitlin wrote:
NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote:
NB> > NB> Here's the thing. Libtool is, by default, designed to transparently
NB> > NB> support the case where
On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote:
NB> On 2/10/16, Bob Friesenhahn wrote:
NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
NB> >> I agree wholeheartedly with the notion that --disable-static should end
NB> >> up in a failure and not somehow degrade to a static build anyway. I
NB>
On Wed, 10 Feb 2016 10:51:02 -0500 Nick Bowler wrote:
NB> The default (on all platforms) is to create both static libraries and,
NB> when possible, shared libraries.
This is not unreasonable (although not obviously the right thing to do
neither IMO), but I'm only speaking, since the beginning o
On Wed, 10 Feb 2016 11:02:29 -0500 Nick Bowler wrote:
NB> On 2/10/16, Vadim Zeitlin wrote:
NB> > On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote:
NB> > NB> On 2/10/16, Bob Friesenhahn wrote:
NB> > NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
NB> > NB
Peter Rosin lysator.liu.se> writes:
> On 2016-02-11 00:38, Bob Friesenhahn wrote:
> >
> > Also, "-no-undefined" does not indicate if the library has undefined
> > symbols (many DLLs have undefined symbols).
Sorry but this is just completely incorrect as written. It's very probable
that you mea
Simon Richter hogyros.de> writes:
> On 10.02.2016 17:49, Vadim Zeitlin wrote:
>
> > *** Warning: Trying to link with static lib archive
/opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a.
> > *** I have the capability to make that library automatically link in when
>
On Sat, 13 Feb 2016 00:38:15 +0100 Peter Rosin wrote:
PR> On 2016-02-12 22:12, Vadim Zeitlin wrote:
PR> > Several concrete questions in this thread asking for any benefits of the
PR> > current libtool behaviour went unanswered, but let me try once again
PR> > nevertheless:
On Sat, 13 Feb 2016 00:38:48 +0100 Peter Rosin wrote:
PR> On 2016-02-12 21:59, Vadim Zeitlin wrote:
PR> > Peter Rosin writes:
PR> >> On 2016-02-11 00:38, Bob Friesenhahn wrote:
PR> >>> It indicates that the build configuration has agreed to supply any
PR> >&
25 matches
Mail list logo
