libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QNX6 patch


From: Ralf Wildenhues
Subject: Re: QNX6 patch
Date: Tue, 12 Apr 2011 23:13:24 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hello Sean,

* Sean Boudreau wrote on Mon, Apr 11, 2011 at 05:32:25PM CEST:
> Here's a patch for qnx that I've been using for a while.
> I'd like to try to get it integrated.

Thank you for the patch.  Unfortunately, we cannot take it as it is,
because there are several bits of information missing, and some things
look problematic.

First off, the patch needs a GNU-style ChangeLog entry (see the
ChangeLog file for existing entries).  We can write it if you have
problems with it, but you should at least try.  Did you write the
patch?  Were others also involved?

Then, we'd like to see how both the old and the new Libtool testsuites
fare with this patch on QNX6 (and maybe older releases if relevant?),
and whether the patch fixes any test failures that were present
previously (and it would be good to see verbose test logs for those as
well).

More comments inline.

> --- libtool-2.4~/libltdl/m4/libtool.m4        2010-09-22 04:41:19.000000000 
> -0400
> +++ libtool-2.4/libltdl/m4/libtool.m4 2011-04-11 11:13:24.000000000 -0400
> @@ -2651,9 +2651,10 @@
>    ;;
>  
>  *nto* | *qnx*)
> -  version_type=qnx
> +  version_type=linux

Whoa, this is a very heavy change.  This has the chance to break
virtually all existing QNX setups, turn installed libraries that have
been built without this change incompatible to libraries that use the
change.

Such a change needs a very good rationale, usually including a pointer
to system documentation for why the old version semantics are not
adequate (any more?), for why maybe a newer system release changed
semantics, or some other reason.  If we do this change for a new system
version, that can be acceptable, but then older versions should not be
affected.

That said, I have no idea how large the user base for Libtool and
Libtool-using packages on QNX is.  You might be the only person building
packages there, I cannot tell.  Please share such information, as much
as you have it.

Jasons remark about this being different from the QNX style makes me
doubt the validity of this change even more.  libtool should be
emulating the native shared library semantics as much as possible in
order to "fit in".

>    need_lib_prefix=no
>    need_version=no
> +  sys_lib_search_path_spec="/lib /usr/lib"

This looks benign.

>    library_names_spec='${libname}${release}${shared_ext}$versuffix 
> ${libname}${release}${shared_ext}$major $libname${shared_ext}'
>    soname_spec='${libname}${release}${shared_ext}$major'
>    shlibpath_var=LD_LIBRARY_PATH
> @@ -3245,7 +3246,7 @@
>    ;;
>  
>  *nto* | *qnx*)
> -  lt_cv_deplibs_check_method=pass_all
> +  'match_pattern /lib[[^/]]+(\.so|S\.a)$'

This looks like a typo.  The resulting shell code is erroneous
(tries to execute a program named "match_pattern /...".
You meant to assign the contents of the added line to the variable
named in the removed line.

>    ;;
>  
>  openbsd*)
> @@ -5289,6 +5290,8 @@
>        ;;
>  
>      *nto* | *qnx*)
> +      _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
> $compiler_flags ${wl}-soname $wl$soname -o $lib'
> +      _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
> $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
> $wl$export_symbols -o $lib'

Please check whether adding $pic_flag to both added commands lets them
still work.

>        ;;
>  
>      openbsd*)
> @@ -6495,7 +6498,12 @@
>       ;;
>  
>        *nto* | *qnx*)
> -        _LT_TAGVAR(ld_shlibs, $1)=yes
> +        _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
> $compiler_flags ${wl}-soname $wl$soname -o $lib'
> +        _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
> $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
> $wl$export_symbols -o $lib'

Likewise.

> +        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
> +        _LT_TAGVAR(hardcode_direct, $1)=yes
> +        _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
> +        output_verbose_link_cmd='echo'

These additions look OK to me.

>       ;;
>  
>        openbsd2*)

Thanks again,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]