On Wed, Jan 18, 2006 at 03:52:33PM +0100, Ralf Wildenhues wrote: > [...] > Ouch. This can get you in trouble, e.g. by a full disk after several > tests with RM=': '. Or, worse, it won't work on systems where the > selected shell does not know $RANDOM. makes sense :) it was just a quick hack to get it working asap, and to see if the problem really lied there.
> Try the patch at the end (not yet tested very much); it should not be > system-specific. ok. just applied and tried a compilation. seems to work correctly. > > The directory hierarchy is some kind of "namespace", handled > > directly by the application itself that takes care of handling path > > problems with dlopen & family. > Does it use libltdl for dlpreopening static components? right now, no. I use simple wrappers around dlopen. However, it is planned to migrate to libtldl. The code that takes care of loading the modules is itself a module, so I guess there won't be many problems to migrate :)... > > libraries. > This may not be necessary, at least there are some situations in which > you may be able to get around double compilation. makes sense. > > If you need to, I can do some tests / checks or provide you with > > the full command lines used to compile the various components, > > or as much help as I can. I'm also open to suggestions... > Either post all `libtool --mode=link' lines including complete output > (also of the convenience libs!), or, even better.. > [...] > ..show the source (in any one of the ways suggested). I'm eager to > see complex real-world setups also to learn more about possible traps > to avoid in libtool. Ok, if you go to: http://www.pigeonair.org/libtool/ you can find: make-all.log - log of the `make all'. Should be easy enough to grep for --mode=link (both stderr and stdout are included) make-install.log - log of the `make install', as above. configure.log - log of the configure output. Pretty much useless. pigeondeliver--main--2.0--patch-174.tar.gz - complete sources of the application + the patch you provided to ltmain.sh + a new configure. (will be committed in patch-175 in the tla tree). Since I usually compile everything in the build directory, with something like: mkdir build && cd build && ../configure ... && make, and since most of the Makefiles are generated at ./configure time, I also provided a: build.tar.gz - with the complete build directory and all the Makefiles generated on my debian system. To access the TLA tree, you can follow the instructions on www.pigeonair.net/main/tla.xml. Make sure to have tla 1.3.x. The problem arises when compiling utils/dscm-dict (in the source tree -- build-custom/dict-dscm in the build tree). The same "double library with same name" is also used by sapi/postfix (build-sapi/runnable/postfix). Only when linking against postfix on a debian system, or on a system with the patch written by LaMont Jones to make postfix compile shared libraries instead of .a files. Note that this is still a public pre-pre-release, and the build system still needs _lot of tuning_ and _lots of work_. There are tons of .m4 macros, too many useless expansions, and a brand new modular structure that still needs many infrastructures. I have still tons of modules to port to this release... The build system is in a very early stage of development, and is very non standard (quite sick right now), even if I'd like to make it generic enough to be detached from pigeondeliver and suitable to make "modular projects" a la php or apache. To get started on a debian system, I'd suggest you to do something like: # apt-get install postfix-dev libldap2-dev $ cd pigeondeliver--main* $ mkdir build && cd build $ bash ../examples/configure/configure.debian.libpostfix (../examples... is an example of how to run the configure) $ make # make install Keep in mind that the build tree has nothing to do with the source tree. The build tree resembles the final namespace that will be used when modules are installed. runnable/loadable/... are all different "methods" that can be used to compile a given component. Right now, it doesn't make much sense. It will as time goes on. Each method is mapped to a file in m4/methods/. I'm open to any suggestion. If you need further details, or you are courious about the structure of the build system, just let me know :) Cheers, Carlo -- GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975 ------------- I'm all for computer dating, but I wouldn't want one to marry my sister. The possession of a book becomes a substitute for reading it. -- Anthony Burgess -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
