Re: Provide a means to activate dynamically the debug traces
Hi all, Le 19 janv. 09 à 10:38, Akim Demaille a écrit : Le 14 janv. 09 à 11:16, Akim Demaille a écrit : Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit : So what do you recommend to store persistent information? A function that returns some static variable (sort of a singleton)? Or an additional argument everywhere (gee...). Maybe I can do it using advices to hand over the verbosity flags, but that does sound like a nuisance for the API. A lt_dlget* and a lt_dlset* function, if the user needs to be able to provide a type. Don't provide the user with a direct pointer if you don't have to. Note that I didn't say global variables are bad, although they are obviously bad, too, for two reasons: slow access, and, well, globality. Assume that you write a library that uses ltdl internally, and I use your library in a program that also links against a completely different library that also uses ltdl. You'll most likely not want interference. Well, in your case I'm not so sure. But if not, then adding a module loading advisor to change verbosity would seem appropriate. I thought about this, and I think that the best option would be to have a callback function with a signature more or less like: void log(void* user_data, level_type level, const char* format, ...); Here is my proposal. There are a few issues on which I'd be happy to have feedback: - I discovered slist only afterwards, and I did not convert my code to use it. I believe it would bring nothing useful, because we really need no specific features here. Using slist would probably require more auxiliary structures and routines. But I can understand the advantages of reusing slist. - This interface is not convenient for messages that are forged in several pieces (first %s, and then %s\n). syslog does not support them, so maybe I should just always require the log message to be a \n-ending line? It is annoying for lt_dlloader_dump. Maybe in this case I should forge a dynamic string first, and log it afterwards, instead of logging several lines. Now every call to the logging functions is given a complete line. I still provide the \n, but maybe I should not. No strong opinion here. - I have not decided what LEVELs should be. We could use syslog's values. No strong opinion here. Or a bitfield? - I have to address stdarg portability, doc, tests, NEWS etc. 0001-Provide-support-for-user-logging-functions.txt Here is an updated version. From 3e75be1a759d060da825a4d828c895234baa2a11 Mon Sep 17 00:00:00 2001 From: Akim Demaille demai...@gostai.com Date: Fri, 9 Jan 2009 14:38:13 +0100 Subject: [PATCH] Provide support for user logging functions. * libltdl/libltdl/lt__debug.h, libltdl/lt__debug.c: New. * libltdl/Makefile.inc, libtoolize.m4sh: Compile/ship/install them. * libltdl/libltdl/lt__private.h: Include lt__debug.h. (lt__log_list): New. * libltdl/libltdl/lt_system.h: Include stdarg.h. * libltdl/ltdl.h (LT_LOG, LT_LOG0, LT_LOG1, LT_LOG2, LT_LOG3) (LT_NONNULL, LT_NAME): New. * libltdl/ltdl.c, libltdl/lt_dlloader.c: Use them. * libltdl/lt_dlloader.c (loader_length_callback) (loader_strcat_callback): New. (lt_dlloader_dump): Rename as... (lt_dllog_loaders): this. (lt_dlloader_dump): Issue full lines. * tests/libtoolize.at: Adjust expected libtoolize output. --- libltdl/Makefile.inc |4 +- libltdl/libltdl/lt__debug.h | 65 + libltdl/libltdl/lt__private.h | 13 +- libltdl/libltdl/lt_dlloader.h |4 +- libltdl/libltdl/lt_system.h |3 +- libltdl/lt__debug.c | 105 + libltdl/lt_dlloader.c | 42 +++-- libltdl/ltdl.c| 62 +++- libltdl/ltdl.h| 23 - libtoolize.m4sh |5 +- tests/libtoolize.at | 12 - 11 files changed, 288 insertions(+), 50 deletions(-) create mode 100644 libltdl/libltdl/lt__debug.h create mode 100644 libltdl/lt__debug.c diff --git a/libltdl/Makefile.inc b/libltdl/Makefile.inc index 0cd982d..7ace644 100644 --- a/libltdl/Makefile.inc +++ b/libltdl/Makefile.inc @@ -1,6 +1,6 @@ ## Makefile.inc -- includable Makefile.am snippet ## -## Copyright (C) 2003, 2004, 2005, 2007 Free Software Foundation, Inc. +## Copyright (C) 2003, 2004, 2005, 2007, 2009 Free Software Foundation, Inc. ## Written by Gary V. Vaughan, 2003 ## ## NOTE: The canonical source of this file is maintained with the @@ -54,6 +54,7 @@ noinst_LTLIBRARIES += libltdl/libltdlc.la endif libltdl_libltdl_la_SOURCES = libltdl/libltdl/lt__alloc.h \ + libltdl/libltdl/lt__debug.h \ libltdl/libltdl/lt__dirent.h \ libltdl/libltdl/lt__glibc.h \ libltdl/libltdl/lt__private.h \
Re: spaces (was: Provide a means to activate dynamically the debug traces)
Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit :
BTW, your editor seems to both reformat existing code, and use
different indenting strategy for new code. Hmm.
Yeah, I know. But fixing the indentation issues progressively does
not
seem bad to me. I certainly don't want these useless differences to
creep into my new code.
This implies that there is a single, well-defined ideal state. Your
editor does not collapse 8 spaces to a TAB, mine (and some others)
does.
This causes whitespace-only changes. Very very minor, I agree, but
still a small irritation when reviewing.
I agree.
Maybe we should update HACKING
about the style we decide about?
(note this is really just bike shedding, and babbling)
I definitely think this would be a good idea.
I have worked for years with the same set up as you, using an much TAB
as is possible. But I read someday something that Jim wrote about
this topic, in which he was advocating the no-tab approach, and I was
convinced. What changed my viewpoint was that (i) Jim is in favor of
it, so it's good :) and (ii) because he did point out that it makes
it really easier to discuss about code in emails. It is true that I
have been disturbed and even annoyed by tab vs. space in some patches
that gave the impression of improper indentation.
Therefore, for a year or so, I am now using spaces only.
Just to give my 0.02€ about this.
The following patch addresses space issues in libtoolize. Some are
benign, some are really dangerous because they invite some editors to
break the code. I speak from experience: I once broke Autoconf
because of sptab - tab cleanup from my editor :( I really
recommend that this patch (or a variation thereof, maybe based on
$lt_sp and $lt_tab) be applied, independently from whether the Libtool
republic votes for tab or space for presidency, as tracking these
issues is uneasy.
From 425171194b41e6627aae75f18dfa5620e8a8c34d Mon Sep 17 00:00:00 2001
From: Akim Demaille demai...@gostai.com
Date: Mon, 19 Jan 2009 09:05:31 +0100
Subject: [PATCH] Clean space uses.
* libtoolize.m4sh: Remove trailing spaces.
Use tabsp, as some editors remove useless spaces in
sptab.
---
libtoolize.m4sh | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 0eefa98..a3aa74d 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -182,7 +182,7 @@ all_pkgltdl_files=COPYING.LIB Makefile Makefile.in
Makefile.inc Makefile.am REA
--install|-i)opt_install=: ;;
--ltdl) opt_ltdl=:
- if test $# -gt 0; then
+ if test $# -gt 0; then
case $1 in
-*) ;;
*) ltdldir=`$ECHO $1 | $SED 's,/*$,,'`
@@ -195,7 +195,7 @@ all_pkgltdl_files=COPYING.LIB Makefile Makefile.in
Makefile.inc Makefile.am REA
--no-warn) opt_warning=false ;;
--nonrecursive|--non-recursive)
- ltdl_mode=nonrecursive
+ ltdl_mode=nonrecursive
;;
--quiet|--automake|-q) # --automake is for 1.5 compatibility
@@ -311,7 +311,7 @@ func_copy_cb ()
copy_return_status=1
# Libtool is probably misinstalled if this happens:
-test -f $my_srcdir/$my_file ||
+test -f $my_srcdir/$my_file ||
func_fatal_error \`$my_file' not found in \`$my_srcdir'
case $opt_verbose in
@@ -375,7 +375,7 @@ func_copy_some_files ()
if test X$my_copy_cb = Xfunc_copy_cb; then
$opt_force || if test -f $my_destdir/$my_filename; then
$opt_quiet || func_echo_once $my_msg_var
- $opt_quiet \
+ $opt_quiet \
|| func_error \`$my_destdir/$my_filename' exists: use \`--force'
to overwrite
continue
fi
@@ -483,12 +483,12 @@ func_scan_files ()
s,^.*AC_REQUIRE(.*$,,; s,^.*m4@t...@_require(.*$,,;
s,^.*m4@t...@_define(.*$,,
s,^.*A[CU]_DEFUN(.*$,,; s,^.*m4@t...@_defun(.*$,,
- /AC_CONFIG_AUX_DIR(/ {
- s,^.*AC_CONFIG_AUX_DIR([[ ]*\([^])]*\).*$,ac_auxdir=\1,
+ /AC_CONFIG_AUX_DIR(/ {
+ s,^.*AC_CONFIG_AUX_DIR([[]*\([^])]*\).*$,ac_auxdir=\1,
p
}
- /AC_CONFIG_MACRO_DIR(/ {
- s,^.*AC_CONFIG_MACRO_DIR([[ ]*\([^])]*\).*$,ac_macrodir=\1,
+ /AC_CONFIG_MACRO_DIR(/ {
+ s,^.*AC_CONFIG_MACRO_DIR([[ ]*\([^])]*\).*$,ac_macrodir=\1,
p
}
/_LT_CONFIG_LTDL_DIR(/d
@@ -503,14 +503,14 @@ func_scan_files ()
}
/the.*option into.*LT_INIT.*parameter/d
/\@:@LT_INIT/d
- /LT_INIT/{
+ /LT_INIT/{
s,^.*$,seen_libtool=:,
p
}
/\@:@LTDL_INIT/d
/LTDL_INIT/ {
- s,^.*LTDL_INIT([[
Re: Provide a means to activate dynamically the debug traces
Le 14 janv. 09 à 11:16, Akim Demaille a écrit : Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit : So what do you recommend to store persistent information? A function that returns some static variable (sort of a singleton)? Or an additional argument everywhere (gee...). Maybe I can do it using advices to hand over the verbosity flags, but that does sound like a nuisance for the API. A lt_dlget* and a lt_dlset* function, if the user needs to be able to provide a type. Don't provide the user with a direct pointer if you don't have to. Note that I didn't say global variables are bad, although they are obviously bad, too, for two reasons: slow access, and, well, globality. Assume that you write a library that uses ltdl internally, and I use your library in a program that also links against a completely different library that also uses ltdl. You'll most likely not want interference. Well, in your case I'm not so sure. But if not, then adding a module loading advisor to change verbosity would seem appropriate. I thought about this, and I think that the best option would be to have a callback function with a signature more or less like: void log(void* user_data, level_type level, const char* format, ...); Here is my proposal. There are a few issues on which I'd be happy to have feedback: - I discovered slist only afterwards, and I did not convert my code to use it. I believe it would bring nothing useful, because we really need no specific features here. Using slist would probably require more auxiliary structures and routines. But I can understand the advantages of reusing slist. - This interface is not convenient for messages that are forged in several pieces (first %s, and then %s\n). syslog does not support them, so maybe I should just always require the log message to be a \n-ending line? It is annoying for lt_dlloader_dump. Maybe in this case I should forge a dynamic string first, and log it afterwards, instead of logging several lines. - I have not decided what LEVELs should be. We could use syslog's values. No strong opinion here. Or a bitfield? - I have to address stdarg portability, doc, tests, NEWS etc. From 031d93cd5e851668bbb8a005273abad32903b88e Mon Sep 17 00:00:00 2001 From: Akim Demaille demai...@gostai.com Date: Fri, 9 Jan 2009 14:38:13 +0100 Subject: [PATCH] Provide support for user logging functions. * libltdl/libltdl/lt__debug.h, libltdl/lt__debug.c: New. * libltdl/Makefile.inc, libtoolize.m4sh: Compile/ship/install them. * libltdl/libltdl/lt__private.h: Include lt__debug.h. (lt__log_list): New. * libltdl/libltdl/lt_system.h: Include stdarg.h. * libltdl/ltdl.h (LT_LOG, LT_LOG0, LT_LOG1, LT_LOG2) (LT_NONNULL, LT_NAME): New. * libltdl/ltdl.c, libltdl/lt_dlloader.c: Use them. * libltdl/lt_dlloader.c (loader_dump_callback): Issue a full line. (lt_dlloader_dump): Issue full lines. * tests/libtoolize.at: Adjust expected libtoolize output. --- libltdl/Makefile.inc |4 +- libltdl/libltdl/lt__debug.h | 63 libltdl/libltdl/lt__private.h | 13 +- libltdl/libltdl/lt_system.h |3 +- libltdl/lt__debug.c | 105 + libltdl/lt_dlloader.c | 15 ++ libltdl/ltdl.c| 59 ++- libltdl/ltdl.h| 23 - libtoolize.m4sh |5 +- tests/libtoolize.at | 12 - 10 files changed, 260 insertions(+), 42 deletions(-) create mode 100644 libltdl/libltdl/lt__debug.h create mode 100644 libltdl/lt__debug.c diff --git a/libltdl/Makefile.inc b/libltdl/Makefile.inc index 0cd982d..7ace644 100644 --- a/libltdl/Makefile.inc +++ b/libltdl/Makefile.inc @@ -1,6 +1,6 @@ ## Makefile.inc -- includable Makefile.am snippet ## -## Copyright (C) 2003, 2004, 2005, 2007 Free Software Foundation, Inc. +## Copyright (C) 2003, 2004, 2005, 2007, 2009 Free Software Foundation, Inc. ## Written by Gary V. Vaughan, 2003 ## ## NOTE: The canonical source of this file is maintained with the @@ -54,6 +54,7 @@ noinst_LTLIBRARIES += libltdl/libltdlc.la endif libltdl_libltdl_la_SOURCES = libltdl/libltdl/lt__alloc.h \ + libltdl/libltdl/lt__debug.h \ libltdl/libltdl/lt__dirent.h \ libltdl/libltdl/lt__glibc.h \ libltdl/libltdl/lt__private.h \ @@ -64,6 +65,7 @@ libltdl_libltdl_la_SOURCES = libltdl/libltdl/lt__alloc.h \ libltdl/libltdl/slist.h \ libltdl/loaders/preopen.c \ libltdl/lt__alloc.c \ + libltdl/lt__debug.c \ libltdl/lt_dlloader.c \ libltdl/lt_error.c \ libltdl/ltdl.c \ diff --git
Re: spaces (was: Provide a means to activate dynamically the debug traces)
On Mon, 19 Jan 2009, Akim Demaille wrote: I have worked for years with the same set up as you, using an much TAB as is possible. But I read someday something that Jim wrote about this topic, in which he was advocating the no-tab approach, and I was convinced. What changed my viewpoint was that (i) Jim is in favor of it, so it's good :) and (ii) because he did point out that it makes it really easier to discuss about code in emails. It is true that I have been disturbed and even annoyed by tab vs. space in some patches that gave the impression of improper indentation. Therefore, for a year or so, I am now using spaces only. It is not necessary to use hard tabs. They are a form of text compression which originated with anchient character terminals and typewriters. Since many/most people have a habit of changing the meaning of TAB to something other than the standard 8 spaces, TAB causes a lot of formatting problems if TAB is used in conjunction with spaces. Text editors have a very hard time agreeing on how to treat TAB and so when TAB is used, the text only appears correct for the person who wrote it. For many years I have had my editor configured to always use spaces. This ensures WYSIWYG for everyone involved. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Provide a means to activate dynamically the debug traces
Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit : So what do you recommend to store persistent information? A function that returns some static variable (sort of a singleton)? Or an additional argument everywhere (gee...). Maybe I can do it using advices to hand over the verbosity flags, but that does sound like a nuisance for the API. A lt_dlget* and a lt_dlset* function, if the user needs to be able to provide a type. Don't provide the user with a direct pointer if you don't have to. Note that I didn't say global variables are bad, although they are obviously bad, too, for two reasons: slow access, and, well, globality. Assume that you write a library that uses ltdl internally, and I use your library in a program that also links against a completely different library that also uses ltdl. You'll most likely not want interference. Well, in your case I'm not so sure. But if not, then adding a module loading advisor to change verbosity would seem appropriate. I thought about this, and I think that the best option would be to have a callback function with a signature more or less like: void log(void* user_data, level_type level, const char* format, ...); (or maybe return an int in the spirit of ltdl to count errors?) It could be given as a new kind of advise for the callback, and the callback user data. It should cover all the needs, and should make it quite easy for C++ users to have wrappers that use the user_data to pass whatever log object they might use. It is no longer ltdl that would decide whether to record or not the message, the level is given to the user. I'm ambivalent wrt level: should it be a magnitude, or a bit-field for the various kinds of event? One problem with the advise-based approach is that not everything works via advisors. For a start lt_init does not. It also makes it somewhat inconvenient for user who decided to use the basic interface to have logs easily. So maybe it should rather be handled as a global inside ltdl, rather than an additional argument passed argument, possibly passed to lt_dlinit*, or even before lt_dlinit. What do you think about it?
Re: Provide a means to activate dynamically the debug traces
* Akim Demaille wrote on Fri, Jan 09, 2009 at 08:56:20PM CET: Le 9 janv. 09 à 19:40, Ralf Wildenhues a écrit : You can instead use libtool --mode=execute -dlopen module.la $program $args Are you saying that the behavior is expected? Why? Why not actually using the *.la in ltdl to be able to load uninstalled dependencies? I had to think about this a bit (most of the code is from before my time). I think it cannot be done portably, at least not without changes to ltmain: On some systems where the shlibpath_var (LD_LIBRARY_PATH) overrides the encoded run paths, libtool exploits this for fast-install: the uninstalled module already has run paths pointing to the installed locations of its deplibs. This means, at 'make install' time, the module does not need to be relinked any more. However, it also means that libltdl would be wrongly loading the old installed deplib. libltdl itself cannot update LD_LIBRARY_PATH, AFAICS glibc only reads it once at program startup. I suppose we could change semantics so that you'd have to pass '-dlopen module' for every module you'd possibly dlopen, at mode=link time of the program. Then this information could be encoded in the program wrapper. However, that would require to always have a wrapper in this case, and the listing of all modules at link time is likely not feasible (they may not yet exist in the build tree). So what do you recommend to store persistent information? A function that returns some static variable (sort of a singleton)? Or an additional argument everywhere (gee...). Maybe I can do it using advices to hand over the verbosity flags, but that does sound like a nuisance for the API. A lt_dlget* and a lt_dlset* function, if the user needs to be able to provide a type. Don't provide the user with a direct pointer if you don't have to. Note that I didn't say global variables are bad, although they are obviously bad, too, for two reasons: slow access, and, well, globality. Assume that you write a library that uses ltdl internally, and I use your library in a program that also links against a completely different library that also uses ltdl. You'll most likely not want interference. Well, in your case I'm not so sure. But if not, then adding a module loading advisor to change verbosity would seem appropriate. For the slow access, hidden visibility can help (not really relevant for this case). BTW, your editor seems to both reformat existing code, and use different indenting strategy for new code. Hmm. Yeah, I know. But fixing the indentation issues progressively does not seem bad to me. I certainly don't want these useless differences to creep into my new code. This implies that there is a single, well-defined ideal state. Your editor does not collapse 8 spaces to a TAB, mine (and some others) does. This causes whitespace-only changes. Very very minor, I agree, but still a small irritation when reviewing. Maybe we should update HACKING about the style we decide about? (note this is really just bike shedding, and babbling) Cheers, Ralf
Provide a means to activate dynamically the debug traces
Hi all, It is sometimes quite a pain in the neck to understand loading failures, especially when they happen on user side and we don't have access to their environment. The following patch attempts to address this issue by giving a means to get debugging information. It should certainly be refined with a means to select the verbosity level (or maybe some bitfield). It helped me track something which I don't understand: when I dlopen a module.la which has a dependency.la library, I expected ltdl to automatically find dependency.la which is not installed. Yet it does not seem to use the module.la's deplibs to dlopen them, it delegates this to the native dlopen. As a result, since my library is not installed, dlopen fails (see dlopen-failure.txt attachement, notice the deplibs line). Of course I can adjust LD_LIBRARY_PATH, but that's not what I expected. Cheers! /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/tests/bin/urbi-launch: --debug --start /dev/null /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch:loaders: lt_dlopen, lt_preopen /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: loading /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/libuobject /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: try_dlopen (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/libuobject, .la) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Parsing *.la file: /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/libuobject.la /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: *.la: dlname: libuobject.dylib /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: *.la: old_name: (null) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: *.la: deplibs: -L/opt/local/lib /Users/akim/src/urbi/2.0/kernel/_build/i386-apple-darwin9.6.0/sdk-remote/lib/libport/libport.la /Users/akim/src/urbi/2.0/kernel/_build/i386-apple-darwin9.6.0/src/lib/sched/libsched.la /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: *.la: installed: 0 /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: *.la: libdir: /usr/local/gostai/core/i386-apple-darwin9.6.0/engine /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: load_deplibs( -L/opt/local/lib /Users/akim/src/urbi/2.0/kernel/_build/i386-apple-darwin9.6.0/sdk-remote/lib/libport/libport.la /Users/akim/src/urbi/2.0/kernel/_build/i386-apple-darwin9.6.0/src/lib/sched/libsched.la): not implemented /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: tryall_dlopen (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/.libs/libuobject.dylib, (ALL)) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Calling lt_dlopen-module_open (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/.libs/libuobject.dylib) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Result: Failed /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Calling lt_preopen-module_open (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/.libs/libuobject.dylib) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Result: Failed /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: tryall_dlopen (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/libuobject.dylib, (ALL)) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Calling lt_dlopen-module_open (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/libuobject.dylib) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Result: Failed /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Calling lt_preopen-module_open (/Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/../src/libuobject.dylib) /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: ltdl: Result: Failed /Users/akim/src/urbi/2.0/sdk-remote/_build/i386-apple-darwin9.6.0/src/.libs/urbi-launch: failed to load
Re: Provide a means to activate dynamically the debug traces
Hi Akim, * Akim Demaille wrote on Fri, Jan 09, 2009 at 04:37:32PM CET: when I dlopen a module.la which has a dependency.la library, I expected ltdl to automatically find dependency.la which is not installed. Yet it does not seem to use the module.la's deplibs to dlopen them, it delegates this to the native dlopen. As a result, since my library is not installed, dlopen fails (see dlopen-failure.txt attachement, notice the deplibs line). Of course I can adjust LD_LIBRARY_PATH, but that's not what I expected. You can instead use libtool --mode=execute -dlopen module.la $program $args Thank you for the patch. I haven't looked at it in detail, but AFAICS it (1) introduces global data symbols, (2) uses them as user-API, and (3) does not annotate them suitably for w32, and (4) doesn't bump the library version numbers accordingly. None of these are ok, unfortunately. Oh, I forgot missing testsuite addition and documentation for new functionality. ;-) I understand that you probably wrote this as a quick hack to get something working. However, IMVHO we should not give in to let such quick hacks into the code base without proper cleanup. FYI, never ever use data (as opposed to function) symbols in a shared library API. Even now that Cygwin is quite usable with them, it will certainly come back to haunt you down the road when you have a better internal representation but are stuck with exposing it. Just don't ever do it. To give a bad precendece example, libltdl did it with lt_preloaded_symbols, and users are suffering because we failed to keep it compatible, and libltdl is suffering because it can't use a faster search inside them. BTW, your editor seems to both reformat existing code, and use different indenting strategy for new code. Hmm. Cheers, Ralf
Re: Provide a means to activate dynamically the debug traces
Le 9 janv. 09 à 19:40, Ralf Wildenhues a écrit : Hi Akim, Hi Ralf, * Akim Demaille wrote on Fri, Jan 09, 2009 at 04:37:32PM CET: when I dlopen a module.la which has a dependency.la library, I expected ltdl to automatically find dependency.la which is not installed. Yet it does not seem to use the module.la's deplibs to dlopen them, it delegates this to the native dlopen. As a result, since my library is not installed, dlopen fails (see dlopen-failure.txt attachement, notice the deplibs line). Of course I can adjust LD_LIBRARY_PATH, but that's not what I expected. You can instead use libtool --mode=execute -dlopen module.la $program $args Are you saying that the behavior is expected? Why? Why not actually using the *.la in ltdl to be able to load uninstalled dependencies? Thank you for the patch. I haven't looked at it in detail, but AFAICS it (1) introduces global data symbols, (2) uses them as user-API, and (3) does not annotate them suitably for w32, and (4) doesn't bump the library version numbers accordingly. None of these are ok, unfortunately. Oh, I forgot missing testsuite addition and documentation for new functionality. ;-) The last two points were expected, but first I wanted to have some feedback. Which you did pretty well :) I understand that you probably wrote this as a quick hack to get something working. However, IMVHO we should not give in to let such quick hacks into the code base without proper cleanup. I agree. FYI, never ever use data (as opposed to function) symbols in a shared library API. OK, will fix. Thanks! Even now that Cygwin is quite usable with them, it will certainly come back to haunt you down the road when you have a better internal representation but are stuck with exposing it. Just don't ever do it. To give a bad precendece example, libltdl did it with lt_preloaded_symbols, and users are suffering because we failed to keep it compatible, and libltdl is suffering because it can't use a faster search inside them. So what do you recommend to store persistent information? A function that returns some static variable (sort of a singleton)? Or an additional argument everywhere (gee...). Maybe I can do it using advices to hand over the verbosity flags, but that does sound like a nuisance for the API. BTW, your editor seems to both reformat existing code, and use different indenting strategy for new code. Hmm. Yeah, I know. But fixing the indentation issues progressively does not seem bad to me. I certainly don't want these useless differences to creep into my new code.
