Re[2]: MSW DLLs support in libtool
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> >>> 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
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: 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: MSW DLLs support in libtool
On 2016-02-12 21:59, Vadim Zeitlin wrote: > Peter Rosin writes: >> On 2016-02-11 00:38, Bob Friesenhahn wrote: >>> 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. The feature here is to not break packages. Changing libtool -no-undefined to imply ld --no-undefined -- at this point -- is not an option IMHO. Also, libtool added -no-undefined before ld added --no-undefined, so some might argue that you are barking up the wrong tree if you think things are inconsistent. Not that shifting blame is going solve anything... Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2016-02-12 22:12, Vadim Zeitlin wrote: > 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? To this specific question, the things that I can think of is if two DLLs (or the app itself) links with slightly different versions of the same static library, that might cause strange bugs. Or if different DLLs link to the same static malloc library and that that in turn produces multiple heaps causing pain should pointers be passed across the DLL boundaries. If libtool should be in the business of protecting from such disasters is another matter... Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
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: MSW DLLs support in libtool
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
On Fri, 12 Feb 2016, Evgeny Grin wrote: option is NOP for anything except W32 and AIX. Moreover, if it does matter only for W32 and AIX, let's rename it to "-w32-aix-shared-compatible". And add more flags, like "-linux-compatible", "-open-bsd-compatible". This will signal libtool that developed checked compatibility of build system with specific OS. We don't do this sort of thing since we have no control over the future and don't know what the future will bring. So we use generic options. If we try to guess what the future may bring then we may guess wrong and someone will take us to task about our bad decisions. For AIX, there is a build mode where shared libraries are more like GNU Linux and not like DLLs. Anyway, what's drawback of assuming "-no-undefined" on W32 and AIX (or on all platforms)? As previously explained, it is more likely to lead to compilation success for packages which have not been crafted/tuned to succeed on targets where -no-undefined makes a difference. A core Autotools principle is that the person compiling the software should be in control as much as possible. This includes people who just received a tarball and are not the developer of the software. Another core principle is that defaulting to imperfect success is better than utter failure. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12.02.2016 20:29, Evgeny Grin wrote:
>
>
> On 12.02.2016 17:28, Nick Bowler wrote:
>> On 2/12/16, Evgeny Grin wrote:
>>> Actually, no. See:
>
>> Just to be sure:
>> Here you are running libtool installed on the system (by path lookup)...
>
>> [...]
>>> /bin/sh ../../libtool --tag=CC --mode=link gcc -fvisibility=hidden
>> [...]
>> ...here you are running a copy of libtool bundled with a package.
>> They are not necessarily the same version.
> They are the same. Project was just reconfigured.
> To be sure:
> $ ./libtool --version
> libtool (GNU libtool) 2.4.6
> Written by Gordon Matzigkeit, 1996
>
>
>> It would be better to provide a test case that others can run.
> I used GNU libmicrohttpd and added to libs extra static-only library by
>
> $ make LIBS=-ltdbcstub103
>
> You can even add non-existing library - result will be the same. Project
> can be any autotools/libtool project.
> I will create minimal working example later.
Minimal example:
configure.ac
-
AC_INIT([libtool_test_01],[0.1.0],[k...@narod.ru])
AM_INIT_AUTOMAKE([foreign])
LT_INIT([win32-dll])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
LDFLAGS="$LDFLAGS -no-undefined"
AC_OUTPUT
-
Makefile.am
-
ACLOCAL_AMFLAGS = -I m4
lib_LTLIBRARIES = libtool_test_01.la
libtool_test_01_la_SOURCES = libtool_test_01.c
-
libtool_test_01.c
-
__declspec(dllexport) int simple_func(int a)
{ return a + 2; }
-
Run:
$ mkdir m4
$ autoreconf -i
$ ./configure --disable-static
$ make
Build lib fine. But:
$ make clean
$ make LIBS=-lnonexistlib
{skip}
*** 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.
Versions:
$ ./libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996
$ autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
$ automake --version
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
$ libtoolize --version
libtoolize (GNU libtool) 2.4.6
Written by Gary V. Vaughan , 2003
- --
Best Wishes,
Evgeny Grin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWvjfQAAoJEL96xKXqwrr0gEIH/jd3sBgGp2Lo2ompPwd90kep
aVCzfeebBF3ABuwZ3VNTL/jEurPPSWL3sH9OAuef9wnZSOgWC0s4qtNxj6tsqaSB
+tEmN6bmr4YdQyljz6MqT2Hb54IL6FU1Yp9zHweHuBVodRFJBExUFBHjfoT7P7ew
PES3aeSsEAXziK0t8qqN8MpYiq4FN595tRcy9yFpzbzSuFn4Icmt8GjybcubT+pX
lgZJ5DRrdDeiamGnLVpOTNlA+5E22hYw5wVuEScOjxVXJj+uuxFvuGJDJlez9wjj
tlwNHj0X+bMm6GLxSp/p9PvqQ6jH2kInO/SuoU7T0DCDcDofJ2XTIceNnXjbM+w=
=F7e6
-END PGP SIGNATURE-
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Mailing Lists
On 12 Feb 2016 15:17, martin wrote: > Please unsubscribe. > > ___ > https://lists.gnu.org/mailman/listinfo/libtool use the link at the bottom of every e-mail to manage your subscription -mike signature.asc Description: Digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12.02.2016 17:28, Nick Bowler wrote: > On 2/12/16, Evgeny Grin wrote: >> Actually, no. See: > > Just to be sure: > Here you are running libtool installed on the system (by path lookup)... > > [...] >> /bin/sh ../../libtool --tag=CC --mode=link gcc -fvisibility=hidden > [...] > ...here you are running a copy of libtool bundled with a package. > They are not necessarily the same version. They are the same. Project was just reconfigured. To be sure: $ ./libtool --version libtool (GNU libtool) 2.4.6 Written by Gordon Matzigkeit, 1996 > It would be better to provide a test case that others can run. I used GNU libmicrohttpd and added to libs extra static-only library by $ make LIBS=-ltdbcstub103 You can even add non-existing library - result will be the same. Project can be any autotools/libtool project. I will create minimal working example later. - -- Best Wishes, Evgeny Grin -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWvhZqAAoJEL96xKXqwrr07LkH/2b+VRpZQVJuj0OXgrHdflab aRGB62THtzvDH4Y9oNmMCj+2xlP7W0UsBjyp3wXsqkZeBdUZzQVa7rypjhBCu5Go lcCGRfHkMJaU62tZUJkHUcvqwrSix7NOPRKszpFUNy6XbKcK5ytIxs8rNe2xRVQj SSXxtkJe6ZxNJnCnRegbnl2vwE5kT4BmudHpRiff+ZVtg0dCHQCDJz3u56WZppyn oE0R/HcXtIa3F/2DU4fwnZ1IdUVBr3ptLGT5esWgJJONMJgLPL/WR4Vh7t516qmr V7ZSXIizhKL78MWAZMz3VvY11zl0PB5bzH2TymoGTVTfBOOJCGllS5YACt22ImM= =ggpi -END PGP SIGNATURE- ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12.02.2016 10:21, Peter Rosin wrote:
> On 2016-02-11 12:23, Evgeny Grin wrote:
>> On 11.02.2016 11:03, Peter Rosin wrote:
>>> Well said, I would also like to add that libtool -no-undefined *does* *not*
>>> imply ld --no-undefined. I.e. If you add libtool -no-undefined, then the
>>> *only* thing that changes is that libtool actually attempts the shared
>>> build.
>> Libtool must attempt to build shared version if configured with
>> "--enable-shared" and must not attempt to build it if configured with
>> "--disable-shared". It's up to linker to fail if shared build is not
>> possible. "Configure" job is to resolve everything that required.
>> On W32 this sounds like "-linker-will-not-fail". Why make any
>> predictions or assumptions if it possible to just try to link?
>
> Below I will discuss the case where no --{en,dis}able-{shared,static}
> options have been given to libtool.
>
> If you have not specified any of the --{enable,disable}-{shared,static}
> options and have a library that have not been declared with
> -no-undefined, libtool may fail on Windows (and AIX) if libtool should
> attempt a shared build. This is the reason why libtool does not even
> attempt it.
But even with this option libtool may fail, right?
So this "-no-undefined" doesn't have real influence on failing. Failure
is depend only on compiler options.
Let's add option "--all-headers-are-present" and do not try
precompile/compile if this option is not specified. Because compiler may
fail if some headers are missing. So better no to try compilation.
Really, try and see the result!
> I'm not certain how it will go if --disable-static (or
> --enable-shared) has been specified w/o -no-undefined, but there are
> two options for libtool. 1) go ahead and try the shared build, or
> 2) fail without trying. I think 2) is what happens, but that there
> used to be a bug which made libtool do a static build anyway. You can
> argue that 1) should happen instead, but I see no reason not to add
> -no-undefined instead, so that libtool can safely build both static
> and shared when no specific --{enable,disable}-{shared,static} is given.
> That is simply much more consistent. I still hate that -no-undefined
> is not the default; it would have been much better to force the odd
> libraries that can't live with that option to declare the reverse
> situation. But alas, that ship has sailed.
I still don't see any real advantage of "-no-undefined". Currently you
must specify it so libtool will be sure, that linking will not fail. But
linking may fail even if this libtool option is specified.
Just remove requirement for in on W32 and AIX. Even libtool reports
"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."
Why duplicate requirement for platform if libtool already know it.
>>> Conditionally adding -no-undefined for systems where it matters is overly
>>> defensive.
>> Not agree.
>> Let's consider that some dev is working on porting some lib to W32 (or
>> AIX). Lib is already ported to
>> Linux/Darwin/FreeBSD/OpenBSD/NetBSD/Solaris/HP-UX. And usually some
>> ports contain OS-specific code parts. This developer need to add
>> "-no-undefined" flag for new port. There are two choices: add flag
>> unconditionally and test lib under all OSes (better - with all possible
>> options and on different OS versions) or just conditionally add flag for
>> specific OS. I bet which way will be chosen.
>
> I still maintain that it is overly defensive, and that the defensive
> behavior is explained by the fact that the libtool -no-undefined flag
> is mixed up with ld --no-undefined. Do you understand that the libtool
> flag is a NOP for all of the preexisting ports in your example?
No, it's still not obvious for me that this flag is NOP for all those
platforms. And I'm sure that it's not obvious not only for me. I didn't
see any documentation that clearly state that libtool "-no-undefined"
option is NOP for anything except W32 and AIX.
Moreover, if it does matter only for W32 and AIX, let's rename it to
"-w32-aix-shared-compatible". And add more flags, like
"-linux-compatible", "-open-bsd-compatible". This will signal libtool
that developed checked compatibility of build system with specific OS.
And do not try to link if flag not specified as link may fail. Later
let's add "-arm-compatible", "-mips-compatible", "-xx64-compatible" and
do not try to compile as compile may fail. Instead of it always
transparently fallback to x86 compilation as it may be useful. Good idea?
Actually, quoted message from libtool produce feeling that
"-no-undefined" will force libtool to link with "--no-undefined" even on
platforms that support undefined symbols. Is it wrong? Or libtool
message is incorrect?
>> Repeat once more: with OS-specific code parts you can't add
>> "-no-undef
Re: MSW DLLs support in libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12.02.2016 0:53, Bob Friesenhahn wrote: > On Thu, 11 Feb 2016, Evgeny Grin wrote: >> On 10.02.2016 18:51, Nick Bowler wrote: >>> The default (on all platforms) is to create both static libraries and, >>> when possible, shared libraries. >> This statement is ether not correct or incorrectly documented. >> Currently "configure --help" show those lib options by default: >> --enable-shared[=PKGS] build shared libraries [default=yes] >> --enable-static[=PKGS] build static libraries [default=yes] >> >> There is not "=auto" option for shared or static versions. Only "yes" or >> "no". >> So, it's explicitly specified whether static will be created and whether >> shared will be created. So "make" must ether create requested versions >> or fail. > > These are 'enable' options. Use of 'enable' implies "best effort". 'enable' also implies 'produce result or fail is result is not possible'. For example, if GCC is configured with "--enable-tls" than TLS will be enabled or GCC will not be built. Same for any other "enable" option. If something is enabled, than enabled option must be present in result if "make" finished without an error, no matter what is printed during building. Currently "--enable-shared" is the *ONLY* exception. It contradicts all other options. If some package cannot be built as shared library, than libtool can print recommendation to try to rebuild it as static library. As package must be rebuild as static. Currently libtool is not helping at this moment. Instead, libtool makes building more difficult is it hiding real errors. A simple example: you are building a set of 20 depend libs for some application (I'm working on Kodi (ex-XBMC) and it's a normal process for release). Libs have inter-dependencies and build up in specific order. If one of the first lib was accidentally failed to build as shared than all dependent libs was not build as shared too. And this will not be detected in the middle of process as "make" succeed. Libtool hides the failure and time of long process of creating all lib chain was wasted. - -- Best Wishes, Evgeny Grin -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWvgPBAAoJEL96xKXqwrr06xUH+wXeTfpH+m5HO9qAS30AXjs2 YZcQxQfncDxec5pRCwpfCqXii8bnhne+kOXeVjDtPugQkCt6fQ66G3oftYYZTpmg PyPJoyGd6s7jogsUYL6ceTmpp5LH/GJ+Yt/lFINlgUcr0vxJBxHlhuSi3xhIpLK9 IEoIyqoVX+yk3hnvNNRbzXVzhOC0FolHkELHlvNXJAk1SGXC774LUGWJ7Ll1HzRu yhQPEjqLXqobXvJauFgAeSgX+HNp2twDLQdvTC/TTLPINuJt+jU+QTN3YgjbiCTh gRdhRiVbOY4wB4JReGBLiNXk7uE1z8UDNTiOqc48cIamhpEX9+hEtC7JVkEC3fY= =SYWA -END PGP SIGNATURE- ___ https://lists.gnu.org/mailman/listinfo/libtool
Mailing Lists
Please unsubscribe. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2/12/16, Evgeny Grin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 12.02.2016 0:14, Nick Bowler wrote: >> On 2/11/16, Evgeny Grin wrote: >>> * change default shared lib mode from "on" to "auto" or "try" and fail >>> if shared lib cannot be created when mode is "on". With that logic >>> "make" will do what requested instead of guessing that "something may be >>> useful even if not requested". Alternatively - introduce new LT_INIT() >>> flag "no-fallback-to-static". >> >> This option already exists. It is called "disable-static". > > Actually, no. See: Just to be sure: > $ libtool --version > libtool (GNU libtool) 2.4.6 > Written by Gordon Matzigkeit, 1996 Here you are running libtool installed on the system (by path lookup)... [...] > /bin/sh ../../libtool --tag=CC --mode=link gcc -fvisibility=hidden [...] ...here you are running a copy of libtool bundled with a package. They are not necessarily the same version. It would be better to provide a test case that others can run. Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12.02.2016 0:14, Nick Bowler wrote:
> On 2/11/16, Evgeny Grin wrote:
>> * change default shared lib mode from "on" to "auto" or "try" and fail
>> if shared lib cannot be created when mode is "on". With that logic
>> "make" will do what requested instead of guessing that "something may be
>> useful even if not requested". Alternatively - introduce new LT_INIT()
>> flag "no-fallback-to-static".
>
> This option already exists. It is called "disable-static".
Actually, no. See:
$ libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ../configure --disable-static
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
{skip}
checking whether to build shared libraries... yes
checking whether to build static libraries... no
{skip}
$ make LIBS=-ltdbcstub103
{skip}
/bin/sh ../../libtool --tag=CC --mode=link gcc -fvisibility=hidden
- -I/mingw64/include -IT:/msys64/mingw64/include
- -IT:/msys64/mingw64/include/p11-kit-1 -IT:/msys64/mingw64/include -g -O2
- -fno-strict-aliasing -LT:/msys64/mingw64/lib -lgnutls -export-dynamic
- -no-undefined -Wl,--output-def,.libs/libmicrohttpd.def -X CClinker
- -static-libgcc -version-info 48:0:36 -o libmicrohttpd.la -rpath
/usr/local/lib libmicrohttpd_la-connection.lo
libmicrohttpd_la-reason_phrase.lo libmicrohttpd_la-daemon.lo
libmicrohttpd_la-internal.lo libmicrohttpd_la-memorypool.lo
libmicrohttpd_la-mhd_mono_clock.lo libmicrohttpd_la-sysfdsetsize.lo
libmicrohttpd_la-mhd_str.lo libmicrohttpd_la-response.lo
libmicrohttpd_la-postprocessor.lo libmicrohttpd_la-digestauth.lo
libmicrohttpd_la-md5.lo libmicrohttpd_la-basicauth.lo
libmicrohttpd_la-base64.lo libmicrohttpd_la-connection_https.lo
../../src/platform/libplatform_interface.la -LT:/msys64/mingw64/lib
- -lgnutls -L/mingw64/lib -lgcrypt -lgpg-error
libmicrohttpd_la-microhttpd_dll_res.lo -ltdbcstub103
libtool: link: rm -fr .libs/libmicrohttpd.a .libs/libmicrohttpd.la
.libs/libmicrohttpd.lai
*** Warning: linker path does not have real file for library
- -ltdbcstub103.
*** 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 libtdbcstub103 and none of the candidates passed a file format
test
*** using a file magic. Last file checked:
T:/msys64/mingw64/lib/libgpg-error.dll.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.
Even after this bug will be fixed, if project configured with
- --enable-static --enable-shared than "make" must create both static and
shared or fail. Just because I requested both, not some combination up
to libtool choice.
- --
Best Wishes,
Evgeny Grin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWveWvAAoJEL96xKXqwrr0q/gH/iD6iA6qgfzYFps7rJnIvEny
OBowzO2WguOQu2sNaD/6X3ketvu4Ooy/p3/k4eDIQm5MkDqu+M7ttuR7wELzApSf
G00Zzt0XFxvw4EWbOYWsotIiVDSYHc5CihvP1xmZJF8XvOqqekC5VMWP8C4FTOP7
mANQK6WqPvk/TdA2EN0CUNhf0bzYX9uXy1GWdgZxNd5ePzeJlDMkV1MgOf20pM/F
gazM7dp+oIBCUW9g6E5bvzcsFYTTe+f3hJWHHB3xShKyUnIcMMdk3dwGNGdcHCMo
DgIk4MYJE6PLc0wI0pEz6cFPfj7sSF0b3khQiT0b0PB6LU2ZJFZx7/d+RbKMxjw=
=cuCE
-END PGP SIGNATURE-
___
https://lists.gnu.org/mailman/listinfo/libtool
