On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin p...@lysator.liu.se 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
On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin p...@lysator.liu.se 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
Charles Wilson libtool at 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
On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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
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.
Den 2011-06-23 14:25 skrev Vadim Zeitlin:
On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin p...@lysator.liu.se 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
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote:
On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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
Charles Wilson libtool at 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
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/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
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote:
On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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
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-import
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 configure[*] is
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
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
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
On Thu, 16 Jun 2011 15:36:24 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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
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 18:15:01 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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
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
20 matches
Mail list logo
