Re: Extend libtool dll namespaces for mingw-w64
On 1/30/2010 06:55, Ralf Wildenhues wrote: That would be fine with me. But I suggest that any policy decision for such a naming change should be done by those projects (MinGW-W64, MinGW, or both), documented there, a flag day announced, and then libtool should follow suit, not the other way round. Hi, I am representing MinGW-W64 and have discussed this with Kai and Nightstrike on IRC. Since all these DLLs all run on Windows, we can't expect users to constantly fiddle with PATH to load the correct DLL, or copy DLLs to every directory where their executables live. One of the objectives in my proposal was to avoid any changes to how libtool behaves with mingw.org. So any changes should be confined to the mingw-w64 side of it. The mingw-w64 project uses the w64 vendor key, while the normal distribution can use any vendor key. So it is a matter of checking for w64 in the vendor key, in addition to any -m32 or -m64 arguments. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
* JonY wrote on Sat, Jan 30, 2010 at 10:47:11AM CET: On 1/30/2010 06:55, Ralf Wildenhues wrote: That would be fine with me. But I suggest that any policy decision for such a naming change should be done by those projects (MinGW-W64, MinGW, or both), documented there, a flag day announced, and then libtool should follow suit, not the other way round. I am representing MinGW-W64 and have discussed this with Kai and Nightstrike on IRC. We are misunderstanding each other. I don't want Libtool to commit to an incompatible change to library creation policy on some system due to hearsay about a conversation on IRC, from someone I can't tell from the website as being official. That is just not sane engineering practice. You guys should get together, write documentation about this on your web site, refer to this page, rebuild your binutils ld to automatically search for the changed prefix when it encounters -lfoo on the command line, and propagate that new binutils to your users. Then, I'm looking at your patch, and only that if you are willing to sign copyright papers; otherwise I don't want to see _any_ patches but will have to reimplement everything based on your existing detailed documentation on how ld and the runtime work together to create, link against, and run programs and shared libraries.[1] If any of the Libtool users come and complain about libtool not linking against their old (or new) libraries after we've made the change, I want to be able to point to your documentation site and tell them we had no choice, upstream had a flag day, tough luck for your proprietary software and you expecting us to remain compatible. Since all these DLLs all run on Windows, we can't expect users to constantly fiddle with PATH to load the correct DLL, or copy DLLs to every directory where their executables live. That's a non-argument. If I understood the rest of the thread correctly, then 64bit Windows will have no problem anyway as it skips 32bit libraries. So all you ever need to do is have one entry in the PATH for 64bit stuff and one for 32bit stuff. I'd even consider installing 64bit packages in a separate --prefix from 32bit ones to be good packaging practice, but that may just be me. One of the objectives in my proposal was to avoid any changes to how libtool behaves with mingw.org. So any changes should be confined to the mingw-w64 side of it. Sure. I understand that you don't represent MinGW, and that you are not interested in working to reunify mingw-w64 and mingw. The mingw-w64 project uses the w64 vendor key, while the normal distribution can use any vendor key. So it is a matter of checking for w64 in the vendor key, in addition to any -m32 or -m64 arguments. OK thanks. Cheers, Ralf [1] My ld.info contains, speaking about cygwin, For instance, when ld is called with the argument `-lxxx' it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a xxx.lib cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. (*) Actually, this is not `cygxxx.dll' but in fact is `prefi.dll', where `prefix' is set by the `ld' option `--dll-search-prefix=prefix'. In the case of cygwin, the standard gcc spec file includes `--dll-search-prefix=cyg', so in effect we actually search for `cygxxx.dll'. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On 30/01/2010 14:56, Ralf Wildenhues wrote: web site, refer to this page, rebuild your binutils ld to automatically search for the changed prefix when it encounters -lfoo on the command Not binutils, I don't think: [1] My ld.info contains, speaking about cygwin, For instance, when ld is called with the argument `-lxxx' it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a xxx.lib cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. (*) Actually, this is not `cygxxx.dll' but in fact is `prefi.dll', where `prefix' is set by the `ld' option `--dll-search-prefix=prefix'. In the case of cygwin, the standard gcc spec file includes `--dll-search-prefix=cyg', so in effect we actually search for `cygxxx.dll'. Yes; this relies entirely on the compiler's LINK_SPEC to pass the correct --dll-search-prefix, as far as I know; W64 team need to do the same with their compiler specs. It's not part of LD itself. cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On 1/30/2010 22:56, Ralf Wildenhues wrote:
If any of the Libtool users come and complain about libtool not linking
against their old (or new) libraries after we've made the change, I want
to be able to point to your documentation site and tell them we had no
choice, upstream had a flag day, tough luck for your proprietary
software and you expecting us to remain compatible.
I see, I will get a wiki entry to explain the change.
Since all these DLLs all run on Windows, we can't
expect users to constantly fiddle with PATH to load the correct DLL, or
copy DLLs to every directory where their executables live.
That's a non-argument. If I understood the rest of the thread
correctly, then 64bit Windows will have no problem anyway as it skips
32bit libraries. So all you ever need to do is have one entry in the
PATH for 64bit stuff and one for 32bit stuff. I'd even consider
installing 64bit packages in a separate --prefix from 32bit ones to be
good packaging practice, but that may just be me.
I misunderstood one of the users who was testing an XP 64bit, it seems
that it does not skip incompatible DLLs like Vista or 7. After some
confirmation, its clear that XP64 does skip properly, so maybe having
the same prefix for 64bit/32bit mingw-w64 DLLs would work.
The --prefix thing may not work for installing multilib GCC though. GCC
could be changed to install DLLs into lib{32,64} so it doesn't get
clobbered on install. This fixup can come later.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
* JonY wrote on Sat, Jan 30, 2010 at 05:29:31PM CET:
I misunderstood one of the users who was testing an XP 64bit, it seems
that it does not skip incompatible DLLs like Vista or 7. After some
confirmation, its clear that XP64 does skip properly, so maybe having
the same prefix for 64bit/32bit mingw-w64 DLLs would work.
No, you're getting it wrong again. If all systems you're interested in
do skip incompatible DLLs properly, then there is *absolutely* no reason
any more to rename them for bitness. Just use different --prefix values
for your binaries, put both bindirs in PATH, and be done with it once
and for all.
Really, please do take advice from people who have struggled with
multilib on other systems. Don't do this renaming thing for bitness,
don't try to handle different binary packages as if you could reunify
them. You'll return next month with renaming for C++ exception
handling, and later for a different calling convention. Argh.
The --prefix thing may not work for installing multilib GCC though.
GCC could be changed to install DLLs into lib{32,64} so it doesn't
get clobbered on install. This fixup can come later.
GCC is a *special* case, to be fixed in the GCC package. Don't confuse
the compiler+tools special cases with the rest of normal packages.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requested will contact all developers as will convince to use macros like @libpre...@foo_ in makefiles and LIBPREFIX is set by configure ? Uhh ... Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
That is just not sane engineering practice. I'd even consider installing 64bit packages in a separate --prefix from 32bit ones to be good packaging practice, GCC is a *special* case, to be fixed in the GCC package. Don't confuse the compiler+tools special cases with the rest of normal packages. I agree fully with Ralf on all points. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On 1/31/2010 02:14, Roumen Petrov wrote: I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requested will contact all developers as will convince to use macros like @libpre...@foo_ in makefiles and LIBPREFIX is set by configure ? Uhh ... Hi, If you looked at the concept patch, it changes how libtool names the DLL by soname_spec, libname_spec stays the same. The makefiles do not see the DLLs at all, only the .la files if libtool is in use. The .la filenames stay the same. That is the whole point of libtool, devs don't need to bother about platform specific details and implementation of shared libs. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
[ moving to libtool@ from automake@; this is http://thread.gmane.org/gmane.comp.sysutils.automake.general/11347/focus=11374 this particular message is about whether the relinking warning and the warning about the need to --finish should be changed to be notices only, which would cause them to not be displayed with `libtool --silent' which implies that an Automake --enable-silent-rules build would not show them at `make install' time. ] If you additionally would like to not see output from libtool, pass LIBTOOLFLAGS=--silent I do so but still see those msgs. It just occurred to me that ltmain.sh could change those line from func_warning to func_verbose instead: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. So the question really is whether to make their life harder for making your life easier. I'd like to know what other libtool people think about this, so feedback appreciated. Thanks, Ralf --- ltmain.sh (revision 57662) +++ ltmain.sh (working copy) @@ -2028,7 +2028,7 @@ relink_command=`$ECHO X$relink_command | $Xsed -e s...@inst_prefix_dir@%%` fi - func_warning relinking \`$file' + func_verbose relinking \`$file' func_show_eval $relink_command \ 'func_fatal_error error: relink \`$file'\'' with the above command before installing it' fi @@ -2269,7 +2269,7 @@ done test -n $future_libdirs \ - func_warning remember to run \`$progname --finish$future_libdirs' + func_verbose remember to run \`$progname --finish$future_libdirs' if test -n $current_libdirs; then # Maybe just do a dry run. ___ http://lists.gnu.org/mailman/listinfo/libtool
