libtool-patches
[Top][All Lists]
Advanced

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

Re: HEAD libltdl/libltdlc ....


From: Ralf Wildenhues
Subject: Re: HEAD libltdl/libltdlc ....
Date: Mon, 5 Feb 2007 21:11:00 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Markus,

Let's keep this on libtool-patches only.

* Duft Markus wrote on Wed, Jan 31, 2007 at 09:20:52AM CET:
> 
> As you can see when looking at the attached gmake check output the (at
> the moment) only leftover failures are due to not finding argz stuff in
> libltdlc.a. the problem with this is, that the agz stuff looked for is
> in libldtl but not in libltdlc. Somehow this is a little strange since
> the Makefile.am states that libltdlc has the same LIBADD and
> DEPENDENCIES.... Is this intentionally??

In your fully up to date build tree, please do the following and post
all its output:
  ./libtool --mode=clean rm -f argz.lo libltdl/argz.lo \
            libltdl/libltdl.la libltdl/libltdlc.la
  make libltdl/libltdl.la libltdl/libltdlc.la

> So argz.o is simply not there in libltdlc.a...... By the way: why are
> there two different versions?

The libltdlc.la is a convenience archive.  AFAIK it's used to avoid
having to link against another uninstalled library in the testsuite.

The following is a rough check, not a full review of the patch.

> diff --exclude=CVS --exclude='Makefile*' -rubB libtool.orig/bootstrap 
> libtool/bootstrap

It's probably easier for you if you put the line
  diff -u

in your ~/.cvsrc file, and run "cvs diff" for generating patches.

Another general comment: please indent according to the rules applied in
the file you're editing.  (For C, the GNU Coding Standards apply, then
there are bits in HACKING, for the rest one should go with what's around
the changes.)

[...]
> diff --exclude=CVS --exclude='Makefile*' -rubB 
> libtool.orig/libltdl/config/ltmain.m4sh libtool/libltdl/config/ltmain.m4sh
> --- libtool.orig/libltdl/config/ltmain.m4sh   2007-01-19 10:47:06.000000000 
> +0100
> +++ libtool/libltdl/config/ltmain.m4sh        2007-01-30 17:57:20.000000000 
> +0100
[...]

> @@ -5225,7 +5233,17 @@
>         last_robj=
>         k=1
>  
> -       if test "X$skipped_export" != "X:" && test "$with_gnu_ld" = yes; then
> +       case "$host_os:$LTCC" in
> +       interix*:*wgcc* | winnt*:*wgcc*)
> +             use_wgcc=yes;;
> +       *)
> +             use_wgcc=no ;;
> +       esac
> +
> +       if test "X$skipped_export" != "X:" && test "$use_wgcc" = yes; then
> +             func_echo "using WGCC, so passing objects on commandline!"
> +             output=${save_libobjs}

Why did you put this here?  Does your command line length never get
exceeded?  Do you support response files?  If yes, then set
file_list_spec in libtool.m4.  Anyway, please avoid if at all possible
mention of system specifics in ltmain.  The idea is to put all system
specifics in libtool.m4 and only the general algorithm into ltmain.

> +       elif test "X$skipped_export" != "X:" && test "$with_gnu_ld" = yes; 
> then


> diff --exclude=CVS --exclude='Makefile*' -rubB 
> libtool.orig/libltdl/lt__dirent.c libtool/libltdl/lt__dirent.c
> --- libtool.orig/libltdl/lt__dirent.c 2007-01-19 10:47:06.000000000 +0100
> +++ libtool/libltdl/lt__dirent.c      2007-01-19 15:42:30.000000000 +0100
> @@ -33,7 +33,7 @@
>  #include "lt__private.h"
>  #include "lt__dirent.h"
>  
> -#if defined(__WINDOWS__)
> +#if defined(__WINDOWS__) && !defined(__WGCC)

This isn't right.  lt__dirent.c should only be compiled if either
of the functions opendir, closedir, readdir, are missing.  If they are
present on your system but configure detects that wrongly, then it needs
to be fixed there (i.e., probably in libltdl/m4/ltdl.m4).  Please look
in the toplevel config.log why that happens.

>  
>  void
>  closedir (DIR *entry)


> diff --exclude=CVS --exclude='Makefile*' -rubB 
> libtool.orig/libltdl/m4/libtool.m4 libtool/libltdl/m4/libtool.m4
> --- libtool.orig/libltdl/m4/libtool.m4        2007-01-19 10:47:05.000000000 
> +0100
> +++ libtool/libltdl/m4/libtool.m4     2007-01-30 13:28:03.000000000 +0100
> @@ -1405,7 +1405,7 @@
>      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
>      ;;
>  
> -  interix*)
> +  interix* | winnt*)
>      # We know the value 262144 and hardcode it with a safety zone (like BSD)
>      lt_cv_sys_max_cmd_len=196608

Is that true (that the value is 262144) or did you add that to shut it
up?

>      ;;

> @@ -2256,6 +2268,45 @@
>    shlibpath_var=LD_LIBRARY_PATH
>    shlibpath_overrides_runpath=no
>    hardcode_into_libs=yes
> +
> +  case "$cc_basename" in
> +  *wgcc*)
> +     hardcode_into_libs=no
> +     shlibpath_var=PATH
> +     sys_lib_search_path_spec=
> +     sys_lib_dlsearch_path_spec=
> +     shlibpath_overrides_runpath=yes
> +     dynamic_linker='windows native linker via wgcc'
> +
> +     # those commands are not perfect... they *may* copy dll's that don't
> +     # belong there (because of the *). This is because the .so file may
> +     # or may not include any combination of version information, and the
> +     # dll includes the version info of the "real" import library, that
> +     # is what was given with -o ... to the linker. (and libtool seems
> +     # to allways give .so.# instead of .so.#.#.# which would be the real
> +     # name ...)
> +     # BUT: normally there is only one dll with a matching name, namely
> +     # the one just built... ;o)
> +
> +     postinstall_cmds='base_file=`basename \${file}`;
> +             dlpath=`$SHELL 2>&1 -c
> +                     '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`;
> +             dldir=$destdir/`dirname \$dlpath`;
> +             for dll in $dir/\$dlname*.dll; do 
> +                     dllname=`basename \\${dll}`;
> +                     test -d \${dldir}/../bin || mkdir -p \${dldir}/../bin;
> +                     $install_prog $dir/`echo \\${dllname}`
> +                             \$dldir/../bin/`echo \\${dllname}`;
> +                     chmod a+x \$dldir/../bin/`echo \\${dllname}`;
> +             done;'

This needs to be rewritten; guess you knew that already.
(Sorry, I need some time and testing for a better review
here.)

> +     postuninstall_cmds='dlpath=`$SHELL 2>&1 -c
> +                     '\''. $file; echo \$dlname'\''`;
> +             for dll in $dir/../bin/\$dlname*.dll; do 
> +                     rm `echo \\$dll`;
> +             done'
> +     ;;
> +     esac
>    ;;
>  
>  irix5* | irix6* | nonstopux*)


> @@ -2779,7 +2830,17 @@
>  m4_defun([_LT_CMD_RELOAD],
>  [AC_CACHE_CHECK([for $LD option to reload object files],
>    lt_cv_ld_reload_flag,
> -  [lt_cv_ld_reload_flag='-r'])
> +  [lt_cv_ld_reload_flag='-r'
> +case $host_os in
> +interix* | winnt*)
> +  case $CC in
> +  *wgcc*)
> +    lt_cv_ld_reload_flag=

So does that mean reloading works in your setup?

> +    ;;
> +  esac
> +  ;;
> +esac
> +]) # _LT_CMD_RELOAD
>  reload_flag=$lt_cv_ld_reload_flag
>  case $reload_flag in
>  "" | " "*) ;;


> diff --exclude=CVS --exclude='Makefile*' -rubB 
> libtool.orig/tests/demo-relink.test libtool/tests/demo-relink.test
> --- libtool.orig/tests/demo-relink.test       2007-01-19 10:46:47.000000000 
> +0100
> +++ libtool/tests/demo-relink.test    2007-01-30 13:57:16.000000000 +0100
> @@ -60,6 +60,9 @@
>  func_msg "removing libhello.la from demo"
>  rm -f libhello.la "$objdir"/libhello.*
>  
> +func_msg "extending PATH for windows"
> +export PATH=${PATH}:$prefix/bin
> +
>  func_msg "running demo/hell"
>  if ./hell; then
>    :

The above is certainly wrong.  Please show the verbose test failure
without this change.


> +/* windows / wgcc definitions of shared library import
> + * wgcc has some benefits over the cygwin/mingw dll handling:

You need to learn not to put down other people's hard work (Cygwin) in
your own, when supplying patches to an independent work (Libtool).
Except for a preference for GNU, Libtool should be neutral in language.

> + * one needs to specify dllimport only, not dllexport since the
> + * compiler exports automatically. Additionally one can pass
> + * dllimport *allways*, except when building the sources them-
> + * selfes. The compiler generates code to support dllimport in
> + * static libraries.
> + */





reply via email to

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