RE: HEAD libltdl/libltdlc ....

[Duft Markus]

Hi,

Ralf Wildenhues <mailto:address@hidden> wrote:
> 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
> 

I'll look into the issue again, but right now i'm having another
problem. After re-bootstrapping now libtool for the first time realizes
ath it may build libltdl as shared library, which gives some linker
errors which i have to look at first ;o//

>> 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.)

Hm, sorry about that, i will have a look at it.

> 
> [...]
>> 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.

Wgcc does not support reloadable objects or response files. So i needed
a way around both. Is there a better solution, somthing like setting one
variable?

> 
>> +      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.
> 

Ok, i need to look at this, since i implement my own dirent within pxwc
(comes with wgcc), but somehow configure fails to link them in *arg*

>> 
>>  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?

If it ever was true, than it probably still is. On winnt (wgcc on
interix) i'm still using the same shell, so it must be the same. I don't
know if it makes any sence hardcoding it here, or if a runtime check
would be better.

> 
>>      ;;
> 
>> @@ -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.)

This allready *is* the re-written version ;o) but i know that it's still
not perfect. But i have not really a good idea on this. I'd need some
help with this!

> 
>> +    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?

No, it doesn't, thats what i wanted to tell by setting it to nothing.
Obviously this is wrong, what should i do?

> 
>> +    ;;
>> +  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.

The output won't help, since a windows messagebox pop's up, telling that
the dll was not found. This is a problem, since libtool does not, and in
my opinion should not know about the installed libraries needed to run
(i think... Is tihs true?). So the user needs to set the PATH manually
(at least for now).

> 
> 
>> +/* 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. 

Sorry about that, i didn't want to do that, as i allready stated in a
mail to the list and Charles Wilson

Kind Regards, Markus

> 
>> + * 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. + */