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> fix --disable-static (and --enabl
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 6/23/2011 11:03 AM, Vadim Zeitlin wrote:
> 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
Den 2011-06-23 14:25 skrev Vadim Zeitlin:
> 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 rig
On Thu, 23 Jun 2011, Vadim Zeitlin wrote:
I.e. it created a shared library with undefined symbols without any
problems because it never actually passed -no-undefined to g++/ld.
In actual practice, it seems difficult or impossible to build programs
under systems like Linux with -no-undefined.
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> In actual practice, it s
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> > checked at all under normal Unix
Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> 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.
If it's
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.
> >>
> >> If it's not doing that, then it's a bug IMO.
> >
> >
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.
>>
>> If it's not doing that, then it's a bug IMO.
>
> Just to confirm: no, currently it doesn't do this. The exampl
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
On 6/20/2011 3:32 AM, Marco atzeri wrote:
> Hi Chuck,
> I guess func_win32_libid() is not failing but the gcc/linker is
> smarter than libtool expect; or that autoconf is misleading libtool.
> /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a
> /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a
> /lib/gcc/
On 6/17/2011 5:49 PM, Charles Wilson wrote:
On 6/17/2011 11:03 AM, Marco atzeri wrote:
Sorry Chuck,
but I can assure you that I am linking against shared dlls,
but the detection is incorrect.
Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a,
and foo-N.dll (plus the -lfoo
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote:
> On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn
> wrote:
> BF> Most projects using libtool come from Unix/Linux where "auto-import"
> BF> is the default so it can be seen that most projects already depend on
> BF> it
>
> My personal exper
On 6/17/2011 11:03 AM, Marco atzeri wrote:
> Sorry Chuck,
> but I can assure you that I am linking against shared dlls,
> but the detection is incorrect.
Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a,
and foo-N.dll (plus the -lfoo incantation) you're using for which the
de
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 trouble accepting
BF> > auto-import m
On 6/17/2011 4:14 PM, Charles Wilson wrote:
On 6/17/2011 3:46 AM, Marco atzeri wrote:
on cygwin
"lt_cv_deplibs_check_method=pass_all"
is my workaround at configure stage to bypass incorrect
libtool detection of system capabilities and to allow
shared libs building.
It's not about "system cap
On 6/17/2011 3:46 AM, Marco atzeri wrote:
> on cygwin
>
> "lt_cv_deplibs_check_method=pass_all"
>
> is my workaround at configure stage to bypass incorrect
> libtool detection of system capabilities and to allow
> shared libs building.
It's not about "system capabilities" in this case. It's abou
Den 2011-06-17 01:15 skrev Bob Friesenhahn:
> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
>> BF>
>> BF> In what way was libtool specifically requested to build a DLL?
>>
>> I'm not sure about the details (please keep in mind that we're speaking
>> about libxml2 here and not my own project) but config
On 6/17/2011 2:10 AM, Bob Friesenhahn wrote:
On Fri, 17 Jun 2011, Vadim Zeitlin wrote:
Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just
too accustomed to the "traditional" Windows way and have trouble
accepting
auto-import magic. It's true that projects using auto-impor
On Fri, 17 Jun 2011, Vadim Zeitlin wrote:
Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just
too accustomed to the "traditional" Windows way and have trouble accepting
auto-import magic. It's true that projects using auto-import could live
with falling back to a static lib
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 in mind that we're speaking
BF> > about libxml2
On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF>
BF> In what way was libtool specifically requested to build a DLL?
I'm not sure about the details (please keep in mind that we're speaking
about libxml2 here and not my own project) but configure[*] is passed
--disable-static option and AFAIK this is
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> > under Windows. And whil
On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
different functions (_foo vs _imp__foo). So IMO creating a static library
when libtool was requested to build a DLL is never the right thing to do
under Windows. And while I hesitate to call this behaviour a bug because it
is clearly intentional, I'd like
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
26 matches
Mail list logo
