Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2
Hi, On Nov 27, 2014, at 4:53 AM, KO Myung-Hun kom...@gmail.com wrote: Gary V. Vaughan wrote: On 27 Nov 2014, at 02:47, KO Myung-Hun kom...@gmail.com wrote: I agree. Gary V. Vaughan wrote: I pushed the core of a new macro that does exactly that to M4 master just now. Would you let me know whether this works correctly on OS2 for you please? Of course. Unfortunately, however, it does not work. dlopen() in configure fails due to 'file not found'. Thanks for checking. Can you tell me why it fails (module is not compiled correctly; path argument to dlopen() is wrong), and maybe suggest what would fix it, please? I've look into this problem. Module is not built. To build it, some additional variables are required. They are soname, libname, output_objdir. And archive_cmds on OS/2 consists of multi lines separated by ~. So when using it, quotation is needed. And to eval it the function such as func_execute_cmds is needed. In addition, make sure .libs exist before building a module. Finally, please remember that OS/2 does not support DLLs whose base name is longer than 8 characters. Thanks for the swift and helpful feedback. I pushed some new changes that should address all of those issues. Please let me know if anything is still wrong, and in what way it is broken for you if so -- otherwise, I'll port this code into a new libtool macro and make the next libtool release for m4 master to depend on. I know I have some other issues you reported to work out in M4, but I'd like to clear this one up first so I can make the promised libtool release asap. Many thanks for your help! Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
[PATCH] libtoolize.in: remove two umask 0
libtoolize --ltdl -c creates some files with write permissions for
everybody because it sets umask 0 in two places. This patch removes
the umask commands.
---
libtoolize.in | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/libtoolize.in b/libtoolize.in
index d819470..530232d 100644
--- a/libtoolize.in
+++ b/libtoolize.in
@@ -392,11 +392,7 @@ func_copy ()
# Filters always take priority.
if test -n $my_filter; then
- if $opt_dry_run || {
- ( umask 0
-$SED -e $my_filter $my_srcfile $my_destfile
- ) /dev/null 21
-}
+ if $opt_dry_run || $SED -e $my_filter $my_srcfile $my_destfile
2/dev/null
then
func_notquiet_once $my_msg_var
if $opt_verbose; then
@@ -422,11 +418,7 @@ func_copy ()
my_copy_msg=$my_copy_type file '$my_destfile'
$opt_verbose my_copy_msg=$my_copycmd $my_srcfile $my_destdir
-if $opt_dry_run || {
-( umask 0
- $my_copycmd $my_srcfile $my_destfile
-) /dev/null 21
- }
+if $opt_dry_run || $my_copycmd $my_srcfile $my_destfile /dev/null 21
then
func_notquiet_hdr $my_msg_var $my_copy_msg
else
--
2.1.0
[PATCH] make freebsd-elf version type similar to linux version type
On FreeBSD we have switched from using .so.$current as library extension to .so.$major.$age.$revision where $major is $current-$age. Our package of libtool has been patched similar to the patch below which you can see here: https://svnweb.freebsd.org/ports/head/devel/libtool/files/ The freebsd-elf version type was also used for SCO UnixWare. This patch creates a separate version type sco for that system. --- build-aux/ltmain.in | 14 ++ m4/libtool.m4 | 5 +++-- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index 65b5a2d..6cea0f8 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -6795,13 +6795,13 @@ func_mode_link () # case $version_type in # correct linux to gnu/linux during the next big refactor - darwin|linux|osf|windows|none) + darwin|freebsd-elf|linux|osf|windows|none) func_arith $number_major + $number_minor current=$func_arith_result age=$number_minor revision=$number_revision ;; - freebsd-aout|freebsd-elf|qnx|sunos) + freebsd-aout|qnx|sco|sunos) current=$number_major revision=$number_minor age=0 @@ -6887,8 +6887,9 @@ func_mode_link () ;; freebsd-elf) - major=.$current - versuffix=.$current + func_arith $current - $age + major=.$func_arith_result + versuffix=$major.$age.$revision ;; irix | nonstopux) @@ -6951,6 +6952,11 @@ func_mode_link () versuffix=.$current ;; + sco) + major=.$current + versuffix=.$current + ;; + sunos) major=.$current versuffix=.$current.$revision diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 320d8b3..acbda77 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -2543,7 +2543,8 @@ freebsd* | dragonfly*) version_type=freebsd-$objformat case $version_type in freebsd-elf*) - library_names_spec='$libname$release$shared_ext$versuffix $libname$release$shared_ext $libname$shared_ext' + library_names_spec='$libname$release$shared_ext$versuffix $libname$release$shared_ext$major $libname$shared_ext' + soname_spec='$libname$release$shared_ext$major' need_version=no need_lib_prefix=no ;; @@ -2888,7 +2889,7 @@ sysv4*MP*) ;; sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*) - version_type=freebsd-elf + version_type=sco need_lib_prefix=no need_version=no library_names_spec='$libname$release$shared_ext$versuffix $libname$release$shared_ext $libname$shared_ext' -- 2.1.0
Re: [PATCH] make freebsd-elf version type similar to linux version type
On Thu, 27 Nov 2014 18:35:00 + Gary V. Vaughan g...@gnu.org wrote: On 27 Nov 2014, at 17:59, Tijl Coosemans t...@freebsd.org wrote: On FreeBSD we have switched from using .so.$current as library extension to .so.$major.$age.$revision where $major is $current-$age. Our package of libtool has been patched similar to the patch below which you can see here: https://svnweb.freebsd.org/ports/head/devel/libtool/files/ What about people who want to build packages for an old BSD a with the earlier versioning scheme? Is it possible to redo your patch so that the change only takes effect for *-freebsdx.y* (or similar) where x.y denotes the earliest release that fully supports the new versioning scheme? FreeBSD has always supported the new scheme. The name of a library doesn't matter at all. I think the reason the old scheme was chosen was because the extension .so.X had always been used for non-libtool libraries and .so.X.Y.Z was unusual.
Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2
Hi/2. Gary V. Vaughan wrote: Hi, On Nov 27, 2014, at 4:53 AM, KO Myung-Hun kom...@gmail.com wrote: Gary V. Vaughan wrote: On 27 Nov 2014, at 02:47, KO Myung-Hun kom...@gmail.com wrote: I agree. Gary V. Vaughan wrote: I pushed the core of a new macro that does exactly that to M4 master just now. Would you let me know whether this works correctly on OS2 for you please? Of course. Unfortunately, however, it does not work. dlopen() in configure fails due to 'file not found'. Thanks for checking. Can you tell me why it fails (module is not compiled correctly; path argument to dlopen() is wrong), and maybe suggest what would fix it, please? I've look into this problem. Module is not built. To build it, some additional variables are required. They are soname, libname, output_objdir. And archive_cmds on OS/2 consists of multi lines separated by ~. So when using it, quotation is needed. And to eval it the function such as func_execute_cmds is needed. In addition, make sure .libs exist before building a module. Finally, please remember that OS/2 does not support DLLs whose base name is longer than 8 characters. Thanks for the swift and helpful feedback. I pushed some new changes that should address all of those issues. Please let me know if anything is still wrong, and in what way it is broken for you if so Great!!! It works perfectly. Thanks a lot. -- otherwise, I'll port this code into a new libtool macro and make the next libtool release for m4 master to depend on. Then, LT_FUNC_DLSYM_USCORE will be fixed ? I know I have some other issues you reported to work out in M4, but I'd like to clear this one up first so I can make the promised libtool release asap. No problem. Many thanks for your help! Thanks for your efforts. ^^ -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr
