[patch #8843] Include _CRTIMP in _putenv() declaration in EXE wrapper sources

[Vadim Zeitlin]

Follow-up Comment #2, patch #8843 (project libtool):

It looks like every 5 years or so I return to this problem, only to confirm
that it's still there and still not fixed. I understand the need to be
patient, but, still, a single word patch languishing for almost 9 years must
be some kind of a record.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: MSW DLLs support in libtool

[Vadim Zeitlin]

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 meant something else from what you wrote, but just to avoid
creating even more confusion in this discussion I'd like to ensure that we
all agree and understand that DLLs (as in "Windows dynamically loaded
libraries") never have any undefined symbols, this is the whole point.

> > It indicates that the build configuration has agreed to supply any
> > additional dependency libraries if there otherwise would be undefined
> > symbols.
> 
> Well said, I would also like to add that libtool -no-undefined *does* *not*
> imply ld --no-undefined.

 This is, of course, a bug. I don't even know if it's worth continuing to
argue because I don't have anything new to add to what I had already
written and it is IMO quite obvious to any user of libtool that it should
imply it, yet most people here seem to consider it as a feature.

 Really, how exactly can the fact that the libtool option with the same
name as a linker option doesn't work in the same way be rationalized?
Especially when libtool is known to reuse the linker options in other cases
(e.g. -shared, -static, ...)? What possible advantage can there be in
allowing to create shared libraries with undefined symbols even if the
libtool library uses -no-undefined?

> I.e. If you add libtool -no-undefined, then the *only* thing that changes
> is that libtool actually attempts the shared build.

 This behaviour is completely nonsensical as well. There is already
--enable-shared for this! Libtool should attempt the shared build if it's
enabled.

> How the shared build is performed is not changed in any way, so
> if there actually are undefined symbols (not supplied by the build etc etc)
> and the platform can handle that, then that will continue to work.

 Or it won't work, but you'll learn about it when the library can't be
loaded on the user's system. Which is, of course, vastly preferable to
getting a link error if libtool passed --no-undefined to linker as every
sane person would expect it to do.

> Conditionally adding -no-undefined for systems where it matters is overly
> defensive.

 Sorry, what does this mean exactly? It's being said that libtool should
leave the control to the application developer. If the application
developer decided to use -no-undefined, why doesn't libtool pass it on to
the linker? Could the application developer intention really be anything
other than this?

 And, conversely, if you insist that libtool -no-undefined should not imply
--no-undefined for ld and should just enable the shared library build, why
is this option used instead of --enable-shared which would seem to be much
better suited to be the option which, well, enables shared libraries?

 I really don't know how to argue against this because whichever way I try
to understand the current libtool behaviour it just doesn't make any sense...

> Repeat after me:
> 
> libtool -no-undefined is not at all the same thing as ld --no-undefined.

 I don't want to repeat it, I want to change this and make -no-undefined
option in a way a reasonable person might expect it to.

 Regards,
VZ



___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Vadim Zeitlin]

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
> > *** you link to this library.  But I can only do this if you have a
> > *** shared version of the library, which you do not appear to have
> > *** because the file extensions .a of this argument makes me believe
> > *** that it is just a static archive that I should not use here.
> 
> Linking a static library into a shared library will only ever work on
> Windows [...]

 Yes, and this is fine. I'll obviously have shared libraries on the other
systems, but why should I have them for Windows too when I don't need them
there?

> On Windows, that is the default behaviour -- all PE binaries are
> completely relocatable, mostly because Windows 3.11 required that. On
> Linux for i386, the dynamic linker supports relocations outside the GOT
> and PIC, which creates unshareable pages and generally sucks, but was
> necessary to port some software back then.

 Thanks, I know all this but it's not really relevant here anyhow. The fact
is that linking non PIC into DLLs works perfectly fine under Windows,
always did and always will. So it makes absolutely no sense whatsoever to
check whether a library contains PIC or not when targeting Windows: you're
checking for something that is completely irrelevant as everything is going
to work no matter what the result of the check is. Except that it currently
doesn't because the check fails and so the shared library is not being
created.

 If this doesn't fit your definition of irony, I don't know what does.

> So support for linking shared into static libraries is essentially
> "win32 only", but creating a special mode for that would make no sense,

 Yes, we agree on this. Last thing we need is an additional mode in
libtool. Instead libtool should just unconditionally skip the check for PIC
when targeting Windows, it's as simple as that. What possible purpose could
there be in checking something that we don't care about anyhow?

> because then the source would no longer be portable and we wouldn't need
> libtool.

 This is a complete non sequitur. My code is quite portable but it uses
static Windows libraries and shared libraries under Unix. So what?

> Boost is a little bit special because they encode the version number and
> several compiler options in the DLL name. Does it link correctly if you
> use the fully decorated name (because that is also what you'd use on Linux)?

 I'm building Boost static libraries manually myself because their
abomination of bjam doesn't support cross-compiling to Windows correctly,
at least in the ancient version of Boost I have to use, so they don't use
decorated names. But this is again irrelevant, even if I can work around
the problem somehow, this problem shouldn't exist in the first place.


 Several concrete questions in this thread asking for any benefits of the
current libtool behaviour went unanswered, but let me try once again
nevertheless: do you see any useful consequences of performing the check
for PIC when targeting Windows in libtool? If you do, what are they
exactly? And if you don't, why do you still think it should be done?

 Thanks in advance,
VZ



___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Sat, 13 Feb 2016 00:38:48 +0100 Peter Rosin <p...@lysator.liu.se> 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> >>> additional dependency libraries if there otherwise would be undefined
PR> >>> symbols.
PR> >>
PR> >> Well said, I would also like to add that libtool -no-undefined does not
PR> >> imply ld --no-undefined.
PR> > 
PR> >  This is, of course, a bug. I don't even know if it's worth continuing to
PR> > argue because I don't have anything new to add to what I had already
PR> > written and it is IMO quite obvious to any user of libtool that it should
PR> > imply it, yet most people here seem to consider it as a feature.
PR> 
PR> The feature here is to not break packages. Changing libtool -no-undefined
PR> to imply ld --no-undefined -- at this point -- is not an option IMHO.

 I'm all for backwards compatibility but it seems ridiculous to me to think
that people would knowingly use libtool -no-undefined when they expect their
libraries to have undefined symbols. IMHO any such "breakage" would only
discover existing bugs. Of course, it's possible that people had to add
-no-undefined to their libtool just to allow it to create DLLs under MSW,
so any such change would absolutely need to be accompanied by the change in
the logic of MSW DLLs generation I'm proposing too.

 But, again, does anybody know of any package that uses -no-undefined but
expects to have undefined symbols in its shared libraries? This would be
just amazing.

PR> Also, libtool added -no-undefined before ld added --no-undefined, so some
PR> might argue that you are barking up the wrong tree if you think things
PR> are inconsistent. Not that shifting blame is going solve anything...

 Again, I don't dispute that some things that don't make sense now did make
sense in the 90s. But the fact is that 20 years have passed since then and
it's time to move on.

 Regards,
VZ


pgp4QtbxEhjiG.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Sat, 13 Feb 2016 00:38:15 +0100 Peter Rosin <p...@lysator.liu.se> 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: do you see any useful consequences of performing the check
PR> > for PIC when targeting Windows in libtool? If you do, what are they
PR> > exactly? And if you don't, why do you still think it should be done?
PR> 
PR> To this specific question, the things that I can think of is if two DLLs
PR> (or the app itself) links with slightly different versions of the same
PR> static library, that might cause strange bugs.

 Thanks, it's an interesting case and I didn't think about it. However
while it's true that bad things can/will happen in this case, wouldn't they
also happen if two DLLs link with the different versions of the same DLL?
It's not totally clear how would you set things up to make the build pick
two different versions of a static library, but  presumably the same could
be done for the import libraries too. Of course, only one DLL would be
effectively loaded into the process address space (unless you have two
import libraries with the same name corresponding to the DLLs with
different names, and if we're considering really perverse cases, why not?),
but one or the other DLL linking with it will crash if the two versions are
not ABI-compatible.

PR> If libtool should be in the business of protecting from such disasters
PR> is another matter...

 I don't think it should and I don't think it can. And I'm also pretty sure
that the current protection against this is, first, unintentional (because
there are surely more direct ways to check for this) and, second, if we
accept that forbidding linking with static libraries completely is worth
this protection in Windows DLL case, then it logically follows that we
should just never link with static libraries at all. And this is (luckily,
I don't want to give anybody any ideas...) not what libtool does.

 So I still think that the check for PIC dependencies under Windows is
useful. Do you, or anybody else, believe it is and can anybody think of any
practical example when it would be useful?

 Thanks,
VZ


pgp0GWdtcMdQU.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[6]: MSW DLLs support in libtool

[Vadim Zeitlin]

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 of this thread,
about the behaviour in LT_INIT(disable-static) case.

NB> If you explicitly request a shared library (i.e., call libtool in
NB> link mode with the -shared option), and it is not possible, you should
NB> receive an error.  If this is not happening, then this is probably a
NB> bug in libtool.

 Using the example posted in reply to another message:

% ./libtool --tag=CXX --mode=link i686-w64-mingw32-g++ -shared -g -O2 -o 
libdlltest.la -rpath /usr/local/lib dlltest.lo
libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 
shared libraries
libtool: link: rm -fr  .libs/libdlltest.a .libs/libdlltest.la 
.libs/libdlltest.lai
libtool: link: i686-w64-mingw32-ar cru .libs/libdlltest.a  .libs/dlltest.o
libtool: link: i686-w64-mingw32-ranlib .libs/libdlltest.a
libtool: link: ( cd ".libs" && rm -f "libdlltest.la" && ln -s 
"../libdlltest.la" "libdlltest.la" )

NB> If libtool is creating static libraries by default when configured with
NB> --disable-static, then that certainly seems like a libtool bug.

 I'm glad we agree about this, I was seriously starting to doubt my sanity.

NB> I just tested it, and the option works as expected for me.  Can you
NB> provide a test case?

 Done in another message.

NB> Note that it is still possible to explicitly request static libraries:
NB> the -static option to libtool will supersede the configure option (as
NB> documented).

 This is not a problem and I don't use this option anyhow.

 Regards,
VZ


pgpPhMn3O_xCs.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

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> >
NB> > Is this not the case?  I have seen builds on Windows fail due to using
NB> > --disable-static.
NB> 
NB> I just tested it on a library which does not specify -no-undefined, and
NB> therefore won't be built as a shared lib on Windows:

 This just doesn't correspond to my experience: when cross compiling from
Linux using libtool 2.4.2, a static library is created. If you want to
reproduce this, just clone https://github.com/vadz/test-libtool-dll and
then do

% libtoolize
% automake --add-missing --foreign
% autoconf
% mkdir build-msw
% cd $_
% ../configure --enable-maintainer-mode --host=i686-w64-mingw32
% make V=0

It does give the following (misleading, as there are no undefined symbols
in this case) message:

libtool: link: warning: undefined symbols not allowed in 
i686-w64-mingw32 shared libraries

but then proceeds with creating a static library.

 I don't know if this works differently under MSYS or if this was fixed
since 2.4.2, but it's definitely broken here.

 Regards,
VZ


pgpf8mAMt2IKY.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[4]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler <nbow...@draconx.ca> wrote:

NB> On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote:
NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <nbow...@draconx.ca> wrote:
NB> > NB> Here's the thing.  Libtool is, by default, designed to transparently
NB> > NB> support the case where building a shared library is not possible.
NB> >
NB> > This is, IMO, an obsolete principle to follow. I admit it made sense in
NB> > the 90s when I first started using libtool and some proprietary Unix
NB> > systems didn't have support for shared libraries or, at least, didn't have
NB> > support for them in libtool.
NB> 
NB> There are still systems where shared library support is limited or not
NB> available at all.  The most obvious is DOS, which still sees some use.

 We can disagree about this, but I just don't think it's reasonable to
create static libraries instead of DLLs under MSW out of concern for DOS.

NB> Next is Microsoft Windows (including Cygwin), where building shared
NB> libraries is not always possible (for example, if the library contains
NB> undefined symbols).

 The request to build a DLL with undefined symbols should result in an
error, not "successfully" building a static library. Again, I can
understand that there can be some doubt about the default behaviour here
and some people may believe that it's better to build anything at all
rather than failing. I completely disagree with this because IMNSHO a low
level tool such as libtool should do what it's told ("create a shared
library") instead of what it thinks would be best. But it seems completely
obvious to me that creating static libraries when disable-static is used is
nothing more than a bug.

NB> Libtool will transparently handles this, by not building shared
NB> libraries when it cannot do so.  The idea is that packages can
NB> still be useful without shared library support.  In my experience,
NB> this works very well.

 In my experience it works horribly. Actually, it just doesn't work.

NB> The -no-undefined option is a signal to libtool: "This library is
NB> compatible with systems that don't support undefined symbols in shared
NB> libraries".  It affects libtool's decision on whether or not a shared
NB> library is possible.

 First of all, this is not even the way it currently works (see points (1)
and (3) of my original message). Second, while philosophically defensible,
this point of view is just singularly unhelpful in practice. As I keep
saying, assuming no-undefined for MSW DLLs would result in better outcomes
in all situations. If I'm missing some situation in which it would be
wrong, nobody has pointed it out yet.

 Regards,
VZ


pgpI1uVcEkfOJ.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[4]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Wed, 10 Feb 2016 11:02:29 -0500 Nick Bowler <nbow...@draconx.ca> wrote:

NB> On 2/10/16, Vadim Zeitlin <va...@zeitlins.org> wrote:
NB> > On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler <nbow...@draconx.ca> wrote:
NB> > NB> On 2/10/16, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote:
NB> > NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
NB> > NB> >> I agree wholeheartedly with the notion that --disable-static
NB> > NB> >> should end up in a failure and not somehow degrade to a static
NB> > NB> >> build anyway.
NB> > NB> >
NB> > NB> > Is this not the case?  I have seen builds on Windows fail due to
NB> > NB> > using --disable-static.
NB> > NB>
NB> > NB> I just tested it on a library which does not specify -no-undefined,
NB> > NB> and therefore won't be built as a shared lib on Windows:
NB> >
NB> > This just doesn't correspond to my experience: when cross compiling from
NB> > Linux using libtool 2.4.2, a static library is created.
NB> 
NB> I cannot reproduce it.  The build fails as expected.
NB> 
NB> Can you reproduce with the latest release of libtool (2.4.6)?  2.4.2 is
NB> very old.

 Damn, don't I feel stupid. This is indeed fixed in the latest version and
the commit fixing it was this one (just don't look at the author)

https://github.com/autotools-mirror/libtool/commit/12641bdc45d091fd1e014d242dcf271237f3c95c

I had completely forgotten that this patch got applied, sorry :-(

 But the problem with not being able to link in static libraries into a DLL
under MSW (the point (3) of the post which started this thread and the one
which I said was the most important for me) remains, even with the latest
master (2.4.6.24-5944f). It does give a long warning:

*** Warning: linker path does not have real file for library -lboost_filesystem.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libboost_filesystem and none of the candidates passed a file format 
test
*** using a file magic. Last file checked: 
/opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

but it still doesn't make any sense. Interestingly enough, if I use the
full path to the static library (instead of "-L$path -lboost_filesystem"),
it says something similar:

*** 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
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.

but then proceeds with creating a DLL.

 Can we agree that this is another bug worth fixing?
VZ


pgpPoOV8870NC.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

[patch #8843] Include _CRTIMP in _putenv() declaration in EXE wrapper sources

[Vadim Zeitlin]

Follow-up Comment #1, patch #8843 (project libtool):

Here is the updated version of the patch for the latest master:

```
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 2a5aaad..0217828 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3663,7 +3663,7 @@ EOF
 /* declarations of non-ANSI functions */
 #if defined __MINGW32__
 # ifdef __STRICT_ANSI__
-int _putenv (const char *);
+_CRTIMP int _putenv (const char *);
 # endif
 #elif defined __CYGWIN__
 # ifdef __STRICT_ANSI__
```

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

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 -no-undefined option. Alas, the fact is that libtool
PR> -no-undefined is not a request to complain if there are undefined
PR> symbols (which, as you say, happens automatically on Windows), it is a
PR> declaration by the library author that there are in fact no undefined
PR> symbols in the library.

 Hello,

 But is this really different? The linker option can also be seen as such
declaration by the library author because if it is not the case, the build
would fail. And this is exactly why MSW linkers have no such options: this
declaration is never needed because it is implicit there.

PR> As for your point about non-trivial programs not working without
PR> special treatment, there are a large body of packages that build just
PR> fine using Cygwin on-top of Windows, without much in the way of special
PR> treatment.

 OK, maybe I underestimated the amount of Unix programs which don't do
anything Unix-specific. But they wouldn't be affected by any changes under
discussion unless they use disable-static, which they hopefully don't.

PR> I agree wholeheartedly with the notion that --disable-static should end
PR> up in a failure and not somehow degrade to a static build anyway. I
PR> also recognize your frustration.

 Thanks, I do appreciate it!

PR> Changing stuff in Libtool to help this situation is therefore extremely
PR> delicate, you risk breaking fragile workarounds that are rarely tested,
PR> if ever. If you change things, you should be quite sure that it does
PR> not cause regressions.

 Well, I think it won't. I could be wrong, of course, but this is one of
the reasons why I tried to explain my reasoning in details in
http://lists.gnu.org/archive/html/libtool/2016-02/msg00015.html
and I hope that if there is any problem with it, someone can point it out.

PR> Another angle on this topic is that I believe that the win32 LT_INIT
PR> option was added to not inflate configure overhead for packages not
PR> supporting Windows (i.e. conforming to your mindset that packages
PR> don't work w/o special treatment anyway). This is still a factor.
PR> Systems like buildroot and gentoo, where packages are built over and
PR> over, do not like if when configure times grow. Making the win32 option
PR> the default would perhaps regress their build times? I think this
PR> point is moot, because I think the overhead of the win32 LT_INIT option
PR> is quite insignificant,

 I agree.

PR> but I don't know that. Maybe it drags in some extra file or something?

 I don't think so, I don't see any difference with and without this option.

PR> Extra files could be an eye-sore to some
PR> puritan. Personally, I don't get why the win32 option exist at all.
PR> I see no reason to discriminate against Windows like that. Make the
PR> no-windows-purists opt out with no-win32 (or whatever) instead.

 I couldn't agree more.

 Regards,
VZ


pgpQ9O3wqaHMK.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

MSW DLLs support in libtool

[Vadim Zeitlin]

 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. By default, libtool _silently_ doesn't create DLLs at all and
   "win32-dll" LT_INIT() option needs to be used just to give it a chance
   to fail. This default looks very unfortunate to me, static libraries are
   almost never the right replacement for the DLLs and finding this option
   when you don't know about it already is not obvious. I'd strongly prefer
   if this option were enabled by default but failing that libtool should
   at least give a noticeable warning if the target platform is MSW and it
   is not enabled and require using no-win32-dll explicitly to disable it.

2. Enabling this option is not enough as you must also painstakingly add
   -no-undefined to all LDFLAGS. Why does libtool need to force you to do
   it instead of just using it unconditionally for all MSW DLLs knowing
   that they can *never* have any undefined symbols? While using this
   option is a good idea for the other platforms too anyhow, there just
   doesn't seem to be any reason to not use it implicitly for MSW, is
   there?

3. If you thought that making the two changes above would be enough to
   finally create the DLLs instead of static libraries, as I did, you would
   be wrong because if any of the DLLs link with any static libraries, it
   will still create static libraries (albeit not silently this time)
   because it fails to check if it can link link the DLL with these static
   libraries. This is extremely frustrating because it has absolutely no
   reason to be checking for anything at all, unlike some other platforms
   (e.g. Linux x86-64), there are no restrictions whatsoever on the
   libraries that the DLLs can be linked with as they don't need to contain
   PIC code under MSW. After some digging around I could work around this
   by doing "lt_cv_deplibs_check_method=pass_all" in configure before
   LT_INIT() but this was far from obvious to find and, of course, not
   guaranteed to work in the future. Why isn't "pass_all" the default (and
   only possibility) for the MSW targets?

4. After all the previous steps I could finally cajole libtool into
   building the DLLs for my lib_LTLIBRARIES but it still silently builds
   static libraries for all my noinst_LTLIBRARIES and I have no idea why.
   I'm giving up for now because this is less critical, but it would still
   need to be fixed if I want to continue using libtool instead of just
   abandoning it (and, by necessity, automake) and going back to hand
   written makefiles.

 The most aggravating thing is that libtool really seems to go out of its
way to make MSW DLLs creation more difficult than it needs to be with all
the tests for things that can never happen. I realize that DLLs are very
different from the typical Unix shared libraries which are libtool's bread
and butter, but surely they're important enough in practice to have some
special handling for them?

 If libtool has a goal of providing decent support for MSW DLLs, I could
try submitting patches changing the things above to work in a more
user-friendly way, but I'd really like to know if they would be welcome
first or if, perhaps, the way things [don't] work now is a subtle hint that
libtool just shouldn't be used if first-tier MSW support is required.

 Thanks in advance for any thoughts,
VZ


pgppR7k3ZSlcv.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <nbow...@draconx.ca> wrote:

NB> On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> 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 with just manual makefiles as both the cross-compiler and
NB> > linker work just fine. Libtool is another matter entirely however:
NB> >
NB> > 1. By default, libtool silently doesn't create DLLs at all and
NB> >"win32-dll" LT_INIT() option needs to be used just to give it a chance
NB> >to fail. This default looks very unfortunate to me, static libraries
NB> >are almost never the right replacement for the DLLs and finding this
NB> >option when you don't know about it already is not obvious. I'd
NB> >strongly prefer if this option were enabled by default but failing that
NB> >libtool should at least give a noticeable warning if the target
NB> >platform is MSW and it is not enabled and require using no-win32-dll
NB> >explicitly to disable it.
NB> 
NB> Here's the thing.  Libtool is, by default, designed to transparently
NB> support the case where building a shared library is not possible.

 Hi,

 This is, IMO, an obsolete principle to follow. I admit it made sense in
the 90s when I first started using libtool and some proprietary Unix
systems didn't have support for shared libraries or, at least, didn't have
support for them in libtool. But this is simply not the case any more since
many, many years and there are just no more systems where building shared
libraries is impossible in common use any longer. But this is a separate
story.

NB> If you don't want to build static libraries, configure with
NB> --disable-static.  Then you will get errors whenever building
NB> a shared library is not possible.

 I'm awfully sorry, I forgot to mention this in my post, but I do use
disable-static in LT_INIT(). The behaviour of libtool with respect to MSW
DLLs would still be wrong, IMHO, even without this option because it's
completely unexpected, but it could at least be argued to be compatible
with the letter, if not the spirit, of its documentation. But this is not
how it works in practice, making it even worse.

 FWIW I'm using libtool 2.4.2 currently, but I looked at the changes in the
latest git and I didn't notice anything that seemed related to this. In any
case, once again, giving an error with disable-static would be better, but
not by much: instead of building static libraries, you now wouldn't be able
to build anything at all. At the very least, disable-static should be
changed to imply win32-dll.

NB> > 2. Enabling this option is not enough as you must also painstakingly add
NB> >-no-undefined to all LDFLAGS. Why does libtool need to force you to do
NB> >it instead of just using it unconditionally for all MSW DLLs knowing
NB> >that they can never have any undefined symbols? While using this
NB> >option is a good idea for the other platforms too anyhow, there just
NB> >doesn't seem to be any reason to not use it implicitly for MSW, is
NB> >there?
NB> 
NB> Because unless you tell it, libtool has no way to know a priori whether
NB> a library will have undefined symbols or not.

 Sorry but this is just not true for the MSW DLLs. If the libtool user
tries to build a DLL, you can safely assume that it will not have undefined
symbols. Anything else just doesn't make sense because it would always
result in an error. Again, this is different from the traditional Unix
shared libraries.

NB> In retrospect, the default (assume undefined symbols are possible) was
NB> probably a bad choice, because undefined symbols in libraries are rarely
NB> used.  Thus, almost all libraries need to specify -no-undefined.  But
NB> this can't be changed now without causing regressions.

 Yes, I understand this and this is why I didn't propose changing it even
if I absolutely agree that it's the wrong default. But I still think it
should be implicit for MSW DLLs because there is no danger of regressions
in this particular case.

NB> > 3. If you thought that making the two changes above would be enough to
NB> >finally create the DLLs instead of static libraries, as I did, you 
would
NB> >be wrong because if any of the DLLs link with any static libraries, it
NB> >will still create static libraries (albeit not silently this time)
...
NB> The nasty warning when you link shared libraries against static libtool
NB> libraries is because this arrangement is not portable, and libtool is
NB> designed to facilitate portable packages.

 I could accept the warning if it then went ahead with creating the DLL,
but falling back to creating a static library

Re[3]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn 
<bfrie...@simple.dallas.tx.us> 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 
undefined
BF> > symbols. Anything else just doesn't make sense because it would always
BF> > result in an error. Again, this is different from the traditional Unix
BF> > shared libraries.
BF> 
BF> Why do you say this?  Most software built using libtool still comes 
BF> from Unix type systems.

 And almost all of it wouldn't compile under MSW. I think it's reasonable
to assume that if an effort was made to port some piece of software to MSW,
it wouldn't have any undefined symbols in its DLLs.

 Of course, if you really want to just compile it and don't care whether
you get static or shared libraries, nothing prevents you from using
--disable-shared and building static libraries only. Contrast this with the
current situation when using --disable-static doesn't change anything at
all and static libraries are still being produced by libtool.

BF> Without the existing behavior it would be difficult to take a program
BF> developed on a Unix type system and just compile it under Windows.

 In practice this is never going to work for any non-trivial program.

BF> It is thought that errors are bad and successful compilation is good.

 I completely and utterly disagree with this. Silently doing the wrong
thing is by far a worse thing to do than giving a clear error indicating
what needs to be done to correct it. Especially if there is no way to
override this "smart" behaviour.

 To be blunt, libtool support for MSW looks like a hack. It has no real
logic and just blindly tries to do everything to produce something,
whatever it is. It might indeed be sufficient if you're just compiling
"Hello world" for MSW and are happy to get whatever you get with the
minimal amount of effort, but it's just not good enough for any real
software where you really do want to get your 10MB DLL and 3 1MB
applications using it instead of getting 3 10MB applications, for example.

 Regards,
VZ

pgpC0NuRNQPLP.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Tue, 9 Feb 2016 21:18:42 -0600 (CST) Bob Friesenhahn 
<bfrie...@simple.dallas.tx.us> 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
BF> >   it instead of just using it unconditionally for all MSW DLLs knowing
BF> >   that they can never have any undefined symbols? While using this
BF> >   option is a good idea for the other platforms too anyhow, there just
BF> >   doesn't seem to be any reason to not use it implicitly for MSW, is
BF> >   there?
BF> 
BF> This is an indication that appropriate steps have been taken to apply 
BF> all needed dependencies at link time.  This is often not the case. 

 Sorry for repeating it again and again but I'd just like to be sure that
we all agree about what happens here because I just can't understand how
can we disagree about the implications if we agree about the facts.

 So let's consider a library which doesn't use -no-undefined. If it really
has any undefined symbols, libtool will currently build a shared library
for it under traditional Unix but (silently!) build a static library under
MSW which is bad enough but could be justified by saying that it's the only
thing that can be done under MSW in this case (I still disagree with this
however and would strongly prefer if libtool gave an error instead if
static libraries are disabled, but ignore this for now).

 But if the library effectively doesn't have any undefined symbols, it
would still produce a shared library under Unix and a static one under MSW
which is just not logical nor useful at all.

 I suggest to change libtool to try to produce a DLL under MSW which seems
obviously more correct as it's always strictly preferable to the current
one: either it will succeed and we'll get what we wanted or it will fail
due to undefined symbols (which are disallowed in a DLL) and we'll get an
error message.

 If you disagree with this, could you please explain why? I.e. in which
situation exactly (undefined symbols present or not) do you believe the
current approach to be superior and why?

BF> Systems like GNU/Linux support implicit dependencies and so sometimes 
BF> an effort is made to not include dependencies, or they may be missed 
BF> by accident.

 Well, that's a perfect example of doing things that encourage usages in
one dominant platform (Linux) to do things which don't work on another one
(MSW)...

BF> > 4. After all the previous steps I could finally cajole libtool into
BF> >   building the DLLs for my lib_LTLIBRARIES but it still silently builds
BF> >   static libraries for all my noinst_LTLIBRARIES and I have no idea why.
BF> 
BF> These are likely "convenience" libraries which are not used as normal 
BF> archive libraries at link time.  Instead all of the objects are 
BF> extracted and applied at link time.  The archive library is used as a 
BF> container rather than a normal archive library.

 I understand this, but it seems strange that it's impossible to build DLLs
without having to install them with libtool. The notions of static/shared
and installable/not-installable are orthogonal and I don't understand why
should libtool conflate them.

BF> It is important that change for Windows do not break the many other 
BF> supported platforms.

 This goes without saying but everything I mentioned so far wouldn't affect
any other platforms at all anyhow.

BF> Your changes are welcome if they assure this and improve reliability
BF> and usability.

 OK, I'll try to make some patches. What is the preferred way of submitting
them? I ask this because I posted a trivial patch here ~5 years ago (see
http://lists.gnu.org/archive/html/libtool-patches/2011-06/msg1.html)
which was never applied, so I also submitted it via Savannah (see
https://savannah.gnu.org/patch/?8843) but this didn't seem to help neither,
and I'm not really sure what else I can do.

 Thanks,
VZ


pgpiXkPjvTXT4.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

[patch #8843] Include _CRTIMP in _putenv() declaration in EXE wrapper sources

[Vadim Zeitlin]

URL:
  

 Summary: Include _CRTIMP in _putenv() declaration in EXE
wrapper sources
 Project: GNU Libtool
Submitted by: zeitlin
Submitted on: Thu 31 Dec 2015 03:12:26 AM CET
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Please see
http://lists.gnu.org/archive/html/libtool-patches/2011-06/msg1.html for
the patch submitted 4.5 years ago but which is still relevant today. The
solution there is not perfect, as discussed on the list, but at least it does
solve the problem and would allow me to build my project without hacking
libtool.

Please consider applying it, TIA!




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)

[Vadim Zeitlin]

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 (and --enable-shared) to error out if it is not
PR possible to create a shared library (due to a missing -no-undefined).

 Sorry for the delay, I got distracted by other things but here is finally
the promised trivial patch (I also cc it to libtool-patches just in case,
sorry if you get this message twice):


From: Vadim Zeitlin vz-libt...@zeitlins.org
Date: Thu, 7 Jul 2011 17:26:43 +0200
Subject: [PATCH] Don't fall back to static libraries if building them was 
disabled.

If -no-undefined was not specified but the platform didn't support shared
libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were
built instead of shared ones, even if building them was explicitly disabled
with --disable-static configure option.

Fix this by stopping with a fatal error if a shared library can't be built in
this case instead of unexpectedly building a static library instead.

* libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when
trying to build a shared library without -no-undefined on a platform not
supporting undefined symbols in shared libraries.

Signed-off-by: Vadim Zeitlin vz-libt...@zeitlins.org
---
 libltdl/config/ltmain.m4sh |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 8e5c588..40b1d5f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6735,9 +6735,12 @@ func_mode_link ()
# Check to see if the archive will have undefined symbols.
if test $allow_undefined = yes; then
  if test $allow_undefined_flag = unsupported; then
-   func_warning undefined symbols not allowed in $host shared 
libraries
-   build_libtool_libs=no
-   build_old_libs=yes
+   if test $build_old_libs = yes; then
+ func_warning undefined symbols not allowed in $host shared 
libraries
+ build_libtool_libs=no
+   else
+ func_fatal_error can't build $host shared library unless 
-no-undefined is specified
+   fi
  fi
else
  # Don't allow undefined symbols.
-- 
1.7.2.3


I've tested this patch with the default and --disable-static configurations
under Windows and Linux and it behaved as expected. Maybe the error message
could be improved but I tried to remain consistent with the existing
warning, if this consideration is not important it might be better to be
more explicit about the problem and its potential solution.


PR But fixing that is a separate issue from what the default behavior
PR should be when -no-undefined is not specified.

 I agree with this but I still disagree that the current default behaviour
is useful. IMO both (C1) and (C3) should try to build a shared library even
if -no-undefined was not given and simply either stop with a fatal error or
fall back to a static library if it failed. I don't see how could getting a
shared library in addition to the static one in the case (C3) could ever be
a problem and getting the expected result in the case (C1) is definitely an
advantage and not a drawback.

 But I won't discuss this any more as I don't have any new arguments and
apparently the ones I already gave were insufficiently convincing.

 Regards,
VZ


pgp8oBjQCFcWr.pgp
Description: PGP signature

Re: [PATCH] Include _CRTIMP in _putenv() declaration in EXE wrapper sources.

[Vadim Zeitlin]

Charles Wilson libtool at cwilson.fastmail.fm writes:

 On 6/23/2011 5:34 AM, Vadim Zeitlin wrote:
  Re-declaring _putenv() without _CRTIMP in strict ANSI mode when using
  MinGW resulted in a warning because of a conflict with the previous
  declaration that did use _CRTIMP.
  
  Simply add _CRTIMP to our declaration to avoid it.
 
  -int _putenv (const char *);
  +_CRTIMP int _putenv (const char *);
 
 Probably should also add __cdecl (for correctness, not warning
 suppression) in case the user has done a -mrtd.
 
 _CRTIMP int __cdecl _putenv (const char*);

 Sorry for the delay, I left aside my struggles with libtool for some time,
but am getting back to it now as I'd really like to not have to return to
this again later.

 It's not totally clear to me if I should make this trivial change myself
or whether this would be done by whoever applies the patch? FWIW I clearly
agree that __cdecl should be there, I just didn't think about -mrtd case.


 However, no need for __MINGW_NOTHROW, I think, because gcc does not
 appear to give this warning when redeclarations only differ by missing
 attributes (in this case, __attribute__ ((__nothrow__)) ).

 I didn't even realize that this was relevant for C code. Anyhow, none of
the versions I tested with warn about it (although I'm pretty sure that it
would warn in C++).

 The larger issue, of course, is that we need to implement
 LT_WRAPPER_CFLAGS variable (*), that strips out warning flags and
 especially -Werror and its other-compiler analogues from the user's
 C[,PP,XX]FLAGS -- otherwise, we will continue to hit this problem over
 and over.
 
 This is the third or fourth time we've had to update the c-wrapper code
 for similar issues.

 I definitely agree that this would be the right approach but I'm afraid
I'm not qualified enough to do it in proper way (mostly because I have no
idea what would such proper way be). So for now I'd just like to fix this
particular problem and hope that no more others arise.

 (*) Dunno what the correct name should be.  LT_CFLAGS_FOR_BUILD or
 similar is /wrong/, because the wrapper is actually built for $host.

 I might be missing something but what's wrong with LT_WRAPPER_CFLAGS? It
seems pretty descriptive and clear to me.

 Thanks,
VZ

PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)

[Vadim Zeitlin]

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 (and --enable-shared) to error out if it is not
PR possible to create a shared library (due to a missing -no-undefined).

 Sorry for the delay, I got distracted by other things but here is finally
the promised trivial patch (I also cc it to libtool-patches just in case,
sorry if you get this message twice):


From: Vadim Zeitlin vz-libt...@zeitlins.org
Date: Thu, 7 Jul 2011 17:26:43 +0200
Subject: [PATCH] Don't fall back to static libraries if building them was 
disabled.

If -no-undefined was not specified but the platform didn't support shared
libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were
built instead of shared ones, even if building them was explicitly disabled
with --disable-static configure option.

Fix this by stopping with a fatal error if a shared library can't be built in
this case instead of unexpectedly building a static library instead.

* libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when
trying to build a shared library without -no-undefined on a platform not
supporting undefined symbols in shared libraries.

Signed-off-by: Vadim Zeitlin vz-libt...@zeitlins.org
---
 libltdl/config/ltmain.m4sh |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 8e5c588..40b1d5f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6735,9 +6735,12 @@ func_mode_link ()
# Check to see if the archive will have undefined symbols.
if test $allow_undefined = yes; then
  if test $allow_undefined_flag = unsupported; then
-   func_warning undefined symbols not allowed in $host shared 
libraries
-   build_libtool_libs=no
-   build_old_libs=yes
+   if test $build_old_libs = yes; then
+ func_warning undefined symbols not allowed in $host shared 
libraries
+ build_libtool_libs=no
+   else
+ func_fatal_error can't build $host shared library unless 
-no-undefined is specified
+   fi
  fi
else
  # Don't allow undefined symbols.
-- 
1.7.2.3


I've tested this patch with the default and --disable-static configurations
under Windows and Linux and it behaved as expected. Maybe the error message
could be improved but I tried to remain consistent with the existing
warning, if this consideration is not important it might be better to be
more explicit about the problem and its potential solution.


PR But fixing that is a separate issue from what the default behavior
PR should be when -no-undefined is not specified.

 I agree with this but I still disagree that the current default behaviour
is useful. IMO both (C1) and (C3) should try to build a shared library even
if -no-undefined was not given and simply either stop with a fatal error or
fall back to a static library if it failed. I don't see how could getting a
shared library in addition to the static one in the case (C3) could ever be
a problem and getting the expected result in the case (C1) is definitely an
advantage and not a drawback.

 But I won't discuss this any more as I don't have any new arguments and
apparently the ones I already gave were insufficiently convincing.

 Regards,
VZ


pgpgD5ub1Glcm.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

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 differ in our understanding of how the
development of a typical project work. You assume that the developers know
in advance everything there is to know about Win32 DLLs and libtool but IME
this is not always the case, especially for the latter. So while I can't
disagree that what you wrote should happen in an ideal case, a more typical
scenario is simply that somebody tries to build the project under Windows.
If there are undefined symbol errors, they will be fixed and maybe, just
maybe, while doing it the person attempting the build will also discover
libtool --no-undefined flag but maybe not even then. What is almost certain
however is that if there are no undefined symbol errors (which is a rather
common case after all) there is going to be much head-scratching because of
libtool seemingly unmotivated refusal to build the shared libraries even
so.

 IOW maybe the simplest solution would be to just include a mention of
--no-undefined in the warning message given by libtool when it decides to
skip building the shared library. E.g. replace the current

libtool: link: warning: undefined symbols not allowed in $host shared libraries

message with something more user-friendly like this:

libtool: link: warning: Skipping the generation of the shared library as
undefined symbols are not allowed in $host shared libraries.
Use -no-undefined option to allow building it if there are really
no undefined symbols.

With the current message it's far from clear that libtool isn't going to
build the shared library (it just warns about something but doesn't say
explicitly what does it mean) nor, most importantly, what can be done about
it.

 2) Once you've gone thru the exercise in #1, now you might as well add
 -no-undefined unconditionally to your libtool invocation -- if you are
 using libtool, that is.

 Exactly! If you don't use libtool, you don't need to do anything special
and can just run the same g++ -shared ... command as under Unix provided
you don't really have any undefined symbols. But if you do use libtool you
need to know to use -no-undefined to prevent libtool from quasi-silently
deciding that your shared library can't be built for you.


 Anyhow, to use the terminology of Peter Rosin's reply, I'm going to resume
my efforts to provide a patch to at least fix this for the case (C1). But
personally I remain convinced that the current behaviour in case (C3) is
very unhelpful. Hopefully at least the warning message could be modified as
proposed above to make it slightly less so.

 Regards,
VZ




___
https://lists.gnu.org/mailman/listinfo/libtool

Re: warning about _putenv redeclaration without dllimport in libtool wrapper script

[Vadim Zeitlin]

Vadim Zeitlin vz-libtool at 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/i686-w64-mingw32/sys-root/mingw/include/stdlib.h but I'm
 not sure if all MinGW versions define _CRTIMP. I did check that 3.4.5,
 4.4.0 and 4.5.0 (native, i.e. not Cygwin) MinGW versions do define it but I
 don't have access to earlier versions any more.
 
  Does anybody know if _CRTIMP is safe to use for all MinGW versions?

 After looking further, I think it is, so I sent the corresponding trivial
patch to libtool-patches.

 Please let me know if you see any problems with it. Thanks,
VZ


___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

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 actual practice, it seems difficult or impossible to build programs 
BF under systems like Linux with -no-undefined.

 I didn't know this but doesn't this make the situation even worse? I.e.
because of the above you can't even recommend people to use -no-undefined
by default. So the default behaviour will remain the current one, i.e. no
DLLs at all under Windows.

BF  I have no idea whether -no-undefined is supposed to work like this but in
BF  any case it seems to me that it's perfectly useless right now. It's not
BF 
BF Not quite useless, but not pedantically useful either.

 Useless and useful are subjective, of course, but what seems undeniably
objective to me is that currently libtool by default doesn't create shared
libraries under Windows at all, even with --disable-static (although,
again, --disable-static shouldn't be considered as a solution for this) and
you need to force it to do it by using -no-undefined explicitly. Moreover,
you may need to do this conditionally, for Windows only, as this could
break things under Linux apparently. And this drastically reduces libtool
usefulness under Windows.


 To put it in another way, currently libtool supposes that a shared library
has undefined symbols by default. There would be nothing intrinsically
wrong with this assumption but it results in clearly broken behaviour. So
IMO it must be changed. I think that ideally libtool should be capable of
determining on its own whether the library has undefined symbols or not.
But if/as this is too difficult to implement, for now a more reasonable
approach would be to admit that libtool doesn't know whether this is the
case and try to do its best with this information and try to create shared
libraries under Windows by default. If -no-undefined is explicitly
specified it wouldn't then change anything for its behaviour under Windows
and similar platforms (AIX?). Finally, some new -has-undefined option might
be introduced to explicitly tell libtool that a library really does have
unresolved external symbols and so can't be built under Windows.

 What do you think?
VZ


pgpNR49pd50KF.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

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 even under Unix where there would be presumably too much
  resistance to change the way --disable-static works if it is controversial
  even under Windows where I thought it would be obviously correct.
  
   So it seems the only solution with any chance of acceptance would be to
  add a different option doing what I want, e.g. --enable-shared-only. Or
  maybe allow --enable-shared=(yes|no|only)?
 
 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 example of my
original message came from libxml2 build configured with --disable-static.

 So should I try to create a patch making libtool fail in this case?

 Thanks,
VZ



___
https://lists.gnu.org/mailman/listinfo/libtool

warning about _putenv redeclaration without dllimport in libtool wrapper script

[Vadim Zeitlin]

 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 the end of the build:

% make test.exe
  ...
  CXXLD  test.exe
cc1: warnings being treated as errors
./.libs/lt-test.c:39:5: error: '_putenv' redeclared without dllimport 
attribute: previous dllimport ignored

Of course, as the cc1: line indicates, usually it's just a warning but
the project I'm working on builds with -Werror so it becomes fatal.

 Of course, the simplest option would be to remove -Werror but I'd prefer
to keep it and correct the warning instead. Unfortunately I don't really
what's the best way to do it. The code of the wrapper script looks like
this:

/* declarations of non-ANSI functions */
#if defined(__MINGW32__)
# ifdef __STRICT_ANSI__
int _putenv (const char *);
# endif

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/i686-w64-mingw32/sys-root/mingw/include/stdlib.h but I'm
not sure if all MinGW versions define _CRTIMP. I did check that 3.4.5,
4.4.0 and 4.5.0 (native, i.e. not Cygwin) MinGW versions do define it but I
don't have access to earlier versions any more.

 Does anybody know if _CRTIMP is safe to use for all MinGW versions? And,
if so, could someone please add it to the libtool code generating this
wrapper script?

 TIA,
VZ


pgpI040f4gxME.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

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  under Windows. And while I hesitate to call this behaviour a bug because 
it
BF  is clearly intentional, I'd like to see it changed because it would have
BF  saved me (and presumably others) a lot of time if libtool simply stopped
BF  with an error after giving the above message instead of valiantly but
BF  ultimately counterproductively trying to continue.
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 handled by AM_PROG_LIBTOOL as
meaning that [only] shared libraries should be built, isn't it?

BF There are certainly cases where proceeding ahead with a static library 
BF is a viable solution.

 Sorry, I can't agree with this when speaking about _Windows_ libraries.
While under a typical Unix system you can link a program with either static
or shared library without changing anything in its code, this is not the
case under Windows as you must either use __declspec(dllimport) or
equivalent or not use it (usually this is governed by some preprocessor
symbols similar to libxml2 LIBXML_STATIC so you need to either define or
not define it). So if the project expects to link with a DLL, producing a
static library is not helpful as linking with it would still fail -- and in
fact this is exactly what happens in my case. Notice that, on the contrary,
if the project can link with a static library then it wouldn't be able to
link with a DLL and so it wouldn't be trying to build it using libtool in
the first place.

 IOW I don't think an example when proceeding ahead is a viable solution is
possible. Do you have anything concrete in mind?

BF If libtool simply refuses to proceed, then many applications will fail
BF to build and users will also be unhappy.

 Again, I don't think such change could break anything because applications
that would rely on this behaviour wouldn't build even right now.

BF What happens if you specify --disable-static to configure?  Does that 
BF help?

 No, --disable-static is already used, in fact, sorry for failing to
mention it in my original message.

 Thanks for your reply,
VZ

[*] See http://git.gnome.org/browse/libxml2/tree/configure.in


pgp4tAgyL34BD.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[3]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

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
BF  about libxml2 here and not my own project) but configure[*] is passed
BF  --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as
BF  meaning that [only] shared libraries should be built, isn't it?
BF 
BF It does seem like falling back to building a static library when 
BF --disable-static has been specified is a bug.

 I didn't think about it from this point of view but now that I do, I can't
help but agree with you ;-)

BF  IOW I don't think an example when proceeding ahead is a viable solution is
BF  possible. Do you have anything concrete in mind?
BF 
BF As it happens, GCC under MinGW and Cygwin does have an auto-import 
BF facility which magically allows it to work for code built with GCC. 

 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 library. But consider that auto-importing is
relatively new so there should be proportionally few projects using it,
hence IMHO the risk of breakage remains reasonably small.

 Anyhow, logically I think there are 3 possible behaviours for libtool:

1. Build static library.
2. Try to build shared library but fall back to static if it failed.
3. Build shared library and give an error if it failed.

 As you wrote, --disable-static would seem to imply (3). If (2) is really
wanted (and I'm still sceptical about it as the set of projects using
auto-import and for which building a DLL is expected, for some reason, to
fail should be very small) it seems like another option is needed, e.g.
--prefer-shared, to choose it.

 Regards,
VZ


pgpDjG6HV5XKB.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool