[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhanced OS/2 port
From: |
KO Myung-Hun |
Subject: |
Re: Enhanced OS/2 port |
Date: |
Thu, 16 Dec 2010 22:50:22 +0900 |
User-agent: |
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1.16) Gecko/20101127 SeaMonkey/2.0.11 |
Hi/2.
Ralf Wildenhues wrote:
> [ adding libtool-patches@; followups can remove libtool@ ]
>
> * KO Myung-Hun wrote on Sun, Nov 28, 2010 at 07:20:32AM CET:
>> I've enhanced and fixed libtool 2.4 for OS/2.
>
> Thanks again for working on this.
>
> Generally, we prefer one patch per logical change, and GNU-style
> ChangeLog entries. Also, we should strive to expose bugs in the
> testsuite, so that we don't regress.
>
> I understand that just producing a patch at all can be hard work,
> so we can help with things (just that takes time ...)
> One thing is quite helpful though, and that's how well our testsuite
> fares on your system (both without and with the patch).
>
> Also, for nontrivial changes, the FSF needs copyright papers
> (more on this off-list).
>
Thanks for your infos. ^^
>
> I'm applying the following patch in your name, and adding you to THANKS:
>
>
> 2010-12-15 KO Myung-Hun <address@hidden> (tiny change)
> Ralf Wildenhues <address@hidden>
>
> Fix PATH_SEPARATOR handling for OS/2.
> * Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
> * libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
> PATH_SEPARATOR.
> * libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
> $progpath.
> * THANKS: Update.
>
> diff --git a/Makefile.am b/Makefile.am
> index 66f38b1..4be353c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
> dist_man1_MANS = $(srcdir)/doc/libtool.1
> $(srcdir)/doc/libtoolize.1
> MAINTAINERCLEANFILES += $(dist_man1_MANS)
> update_mans = \
> - PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
> + PATH=".$(PATH_SEPARATOR)$$PATH"; export PATH; \
> $(HELP2MAN) --output=$@
> $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
> $(update_mans) --help-option=--help-all libtool
> diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
> index 44a7ce9..40d5413 100644
> --- a/libltdl/config/general.m4sh
> +++ b/libltdl/config/general.m4sh
> @@ -296,7 +296,7 @@ case $progpath in
> ;;
> *)
> save_IFS="$IFS"
> - IFS=:
> + IFS=${PATH_SEPARATOR-:}
> for progdir in $PATH; do
> IFS="$save_IFS"
> test -x "$progdir/$progname" && break
> diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
> index 1f61140..ab3e16f 100644
> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
> AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
> AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
>
> +_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build
> system])dnl
> +dnl
> _LT_DECL([], [host_alias], [0], [The host system])dnl
> _LT_DECL([], [host], [0])dnl
> _LT_DECL([], [host_os], [0])dnl
>
>
Thanks a lot. ^^
>
>
>> @@ -564,6 +567,10 @@
>
> (in func_show_eval)
>
>> my_cmd="$1"
>> my_fail_exp="${2-:}"
>>
>> + # pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
>> + # when a line length is 1022. Maybe 1022 is a magic number ?
>> + my_cmd=`$ECHO "$my_cmd" | $SED s/\r$//`
>
> Ouch. Where did you hit this? Can't you fix pdksh instead?
> This change unconditionally costs two forks and one exec on almost every
> command that libtool issues. Also, \r is not a portable sed regex.
>
> Does something like this work instead?
>
> # pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
> # when a line length is 1022.
> case $my_cmd in *$'\r')
> my_cmd=`$ECHO "$my_cmd" | $SED s/\r$//` ;;
> esac
>
> What about this?
> cr=$'\r'
> case $my_cmd in *$cr)
> my_cmd=`$ECHO "$my_cmd" | $SED s/\r$//` ;;
> esac
>
> Then we still need to factor setting of $cr, but at least it's not quite
> so expensive on other systems.
>
Ok, you can ignore this hunk. I've found the cause. This occurs if
sh.exe is in PATH as well as /bin. Removing sh.exe in PATH resolved this
problem.
>> # don't eliminate duplications in $postdeps and $predeps
>> opt_duplicate_compiler_generated_deps=:
>> ;;
>
>
>> @@ -1638,6 +1638,7 @@
>> -rpath LIBDIR the created library will eventually be installed in
>> LIBDIR
>> -R[ ]LIBDIR add LIBDIR to the runtime path of programs and libraries
>> -shared only do dynamic linking of libtool libraries
>> + -shortname NAME specify a short name for a DLL(effect on OS/2 only)
>> -shrext SUFFIX override the standard shared library file extension
>> -static do not do any dynamic linking of uninstalled libtool
>> libraries
>> -static-libtool-libs
>
> This change and associated other hunks should be in a separate patch on
> its own, with an accompanying NEWS entry and addition to
> doc/libtool.texi.
>
I attach the patch.
>> @@ -2221,8 +2222,17 @@
>> # so we also need to try rm && ln -s.
>> for linkname
>> do
>> - test "$linkname" != "$realname" \
>> - && func_show_eval "(cd $destdir && { $LN_S -f $realname
>> $linkname || { $RM $linkname && $LN_S $realname $linkname; }; })"
>> + if test "$linkname" != "$realname"; then
>> + case $host_os in
>> + os2*)
>> + # Create import libraries instead of links on OS/2
>> + func_show_eval "(emximp -o $destdir/$linkname
>> $dir/${linkname%%_dll.$libext}.def)"
>
> Can this instead be handled in a similar manner to how import libraries
> are handled on MinGW and Cygwin?
>
Although it will take a long time, I think it is possible. However, if
acceptable, I wouldn't. Because OS/2 does not support links at all. So
how should links be processed on OS/2 ? In addition, library_names
consist of dll and import lib on OS/2. So linking a import lib to a dll
is useless.
> Also, hard-coding 'emximp' does not seem like a good idea. It should be
> either searchable or overridable,
What do you mean by 'searchable' and 'overridable' ? If I understood
them correctly, emximp is searchable in PATH. And I don't think there is
and will be a tool to override emximp on OS/2.
> and the relevant commands should be in
> a *_cmds variable in libtool.m4 (see above).
>
Ok, I'll try later.
> If the DLL is put in the bindir (is that common on OS/2?) then should
> the import library reside in libdir (as is common on w32) or alongside
> the DLL?
>
libdir is common on OS/2. And the import library should reside in it.
>> @@ -4628,6 +4638,11 @@
>> prev=
>> continue
>> ;;
>> + shortname)
>> + shortname_cmds="$ECHO $arg | cut -b -8"
>
> Why do you use a cutoff here? It would seem to me that if the user
> wanted to hard-code the name, then she should have the freedom to set
> the length. Otherwise, I'd prefer to at least not hardcode the 8 here,
> but use an _LT_DECL shortname_max or so and set it from libtool.m4
> (with 0 denoting no limit, for example).
>
As you see in a comment for -shortname, OS/2 itself limits a length of a
basename of DLL to 8 bytes. So even though the user specify the longer
name than 8 bytes intentionally, it should be forbidden. Otherwise, the
DLL cannot be loaded by OS/2 loader.
>> @@ -4947,6 +4962,14 @@
>> continue
>> ;;
>>
>> + -shortname)
>> + # OS/2 limits a length of a DLL basename up to 8 characters.
>> + # So there is need to use a short name instead of a original name
>> + # longer than 8 characters.
>
> This comment would rather belong to libtool.m4 where shortname_cmds is
> set.
>
Ok.
> [... rest will be reviewed in another mail ...]
>
Thanks. ^^
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.0.11
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
shortname.diff
Description: Text Data