You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <ma...@biol.unipr.it> on 2006/12/15 16:30:35 UTC
Re: escape_string in 1_0
David Welton wrote:
>> ok, I changed it by hand. 'svn diff' produces a patch quite similar
>> to the one you passed me. I compiled and restarted apache
>>
>> Cannot load /home/manghi/Projects/rivet/1_0/src/.libs/mod_rivet.so
>> into server:
>> /home/manghi/Projects/rivet/1_0/src/.libs/mod_rivet.so: undefined
>> symbol: Rivet_Init
>>
>> I'm not an expert of the autotools galaxy, but Makefile.am in src
>> is quite simple. The only thing I can say is that I don't see
>> a clear connection between mod_rivet.so and librivet.so expressed
>> in this file. Therefore I don't know if it's correct to expect the
>> 2 library to link up dynamically. As someone wrote in src/Makefile.am,
>> autotools are 'weird and magic' and being a magician is not everybody's
>> art, so i can be missing totally the point.
>
> Hrm... bizarre. I'll see if I can take a look at that some time this
> week.
>
Hi David, I'm getting out of a really busy time (lectures, kids flue etc)
I made Rivet work again by statically linking the libraries into the module.
This is obtained simply appending $(lib_libexec_LTLIBRARIES) to
mod_rivet_la_LIBADD in src/Makefile.am. No fancy autotools macros.
'configure' complains about the non portability of the method,
but at least I got the module into apache again with the commands I
wanted to have.
the question now is: where mod_rivet.so expects to find librivet.so and
librivetparser.so? /usr/lib didn't work and lib_libexecdir didn't
work either... the latter is evaluated as /usr/share/rivet0.7.0
any hint?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: escape_string in 1_0
Posted by David Welton <da...@gmail.com>.
> I can see more than two problems with the current setup - especially
> since the whole autoconf/automake is broken.
> Some time ago I proposed a different setup, also in order to port Rivet
> for Apache2 more effectively. My proposal is to split the distribution
> in 3 parts (or two parts): The Rivet/Tcl extension, the common TclWeb
> related things and the two modules for Apache1.x and Apache2.x.
> The question is, how appropriate it is to separate the Tclweb stuff (the
> files in src/ directly) from the modules... but I definitely think that
> the Rivet Tcl extension should evolve separately from the modules.
>
> That would make the maintenance much easier - for the Rivet Tcl
> extension, the standard TEA platform can be utilized, as available
> through anonymous CVS from
> http://tcl.cvs.sourceforge.net/tcl/sampleextension/
> For the modules, the apache/libtool stuff can be used, described e.g. in
> the tutorial here:
> http://threebit.net/tutorials/apache2_modules/tut1/tutorial1.html
>
> I think this makes it easier to ensure that the libs are correctly in
> place during install. It would require to start the configuration from
> scratch, and maybe to do a completely fresh svn import with the new
> setup. But then, it would at least be possible to continue the work on
> the Apache2.x port effectively and maintain the other things. So it's a
> single, relatively small step (since the current setup does not work
> anyway) with a big benefit.
If you're willing to have a stab at this, I'll make sure that it gets
into the HEAD.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: escape_string in 1_0
Posted by Massimo Manghi <ma...@biol.unipr.it>.
I completely missed the fact auto*things* were broken
when applied to this project. I'm perfectly conscious of
the very insidious nature of the autotools but Rivet at
first didn't look like a treacherous project to build.
Enough. I will continue the development with a module
that includes the whole bunch of the library sources
(rivetWWW.c, rivetCrypt.c...).
you have a vision for reorganizing Rivet in a more
manageable way and David has virtually accepted
to explore the proposal. Why don't you make a
more precise outline of which component/file/directory
should go in which package?
-- Massimo
Eckhard Lehmann wrote:
> Massimo,
>
> I can see more than two problems with the current setup - especially
> since the whole autoconf/automake is broken.
> Some time ago I proposed a different setup, also in order to port Rivet
> for Apache2 more effectively. My proposal is to split the distribution
> in 3 parts (or two parts): The Rivet/Tcl extension, the common TclWeb
> related things and the two modules for Apache1.x and Apache2.x.
> The question is, how appropriate it is to separate the Tclweb stuff (the
> files in src/ directly) from the modules... but I definitely think that
> the Rivet Tcl extension should evolve separately from the modules.
>
> That would make the maintenance much easier - for the Rivet Tcl
> extension, the standard TEA platform can be utilized, as available
> through anonymous CVS from
> http://tcl.cvs.sourceforge.net/tcl/sampleextension/
> For the modules, the apache/libtool stuff can be used, described e.g. in
> the tutorial here:
> http://threebit.net/tutorials/apache2_modules/tut1/tutorial1.html
>
> I think this makes it easier to ensure that the libs are correctly in
> place during install. It would require to start the configuration from
> scratch, and maybe to do a completely fresh svn import with the new
> setup. But then, it would at least be possible to continue the work on
> the Apache2.x port effectively and maintain the other things. So it's a
> single, relatively small step (since the current setup does not work
> anyway) with a big benefit.
>
>
> Eckhard
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: escape_string in 1_0
Posted by Eckhard Lehmann <ec...@web.de>.
Massimo,
I can see more than two problems with the current setup - especially
since the whole autoconf/automake is broken.
Some time ago I proposed a different setup, also in order to port Rivet
for Apache2 more effectively. My proposal is to split the distribution
in 3 parts (or two parts): The Rivet/Tcl extension, the common TclWeb
related things and the two modules for Apache1.x and Apache2.x.
The question is, how appropriate it is to separate the Tclweb stuff (the
files in src/ directly) from the modules... but I definitely think that
the Rivet Tcl extension should evolve separately from the modules.
That would make the maintenance much easier - for the Rivet Tcl
extension, the standard TEA platform can be utilized, as available
through anonymous CVS from
http://tcl.cvs.sourceforge.net/tcl/sampleextension/
For the modules, the apache/libtool stuff can be used, described e.g. in
the tutorial here:
http://threebit.net/tutorials/apache2_modules/tut1/tutorial1.html
I think this makes it easier to ensure that the libs are correctly in
place during install. It would require to start the configuration from
scratch, and maybe to do a completely fresh svn import with the new
setup. But then, it would at least be possible to continue the work on
the Apache2.x port effectively and maintain the other things. So it's a
single, relatively small step (since the current setup does not work
anyway) with a big benefit.
Eckhard
Am Mittwoch, den 20.12.2006, 10:14 +0100 schrieb Massimo Manghi:
> Thank you Eckhard,
>
> I expect mod_rivet to be able to load the libraries if they are
> in /usr/lib. This is at least a general assumption on Debian/Linux
> and, for what I know, on every other Unix-like os.
>
> I can see 2 problems with Rivet set up:
>
> 1) make install fails to actually copy the 2 libraries
> (librivetparser.so,librivet.so)
> in either /usr/lib or /usr/share/rivet0.7.0 (see src/Makefile.am):
>
> for instance, when 'make install' attempts to install librivetparser.so
>
> /usr/bin/install -c .libs/librivetparser.so /usr/lib
> /usr/share/rivet0.7.0/librivetparser.so
> /usr/bin/install: target `/usr/share/rivet0.7.0/librivetparser.so' is
> not a directory
>
> the form of the command 'install' is actually wrong (install <options>
> <source> <dest. dir>).
> It seems that lib_libexecdir is used by configure in order to establish
> the target
> for 'install'. But this symbol is a 2 directory list (apache libs
> directory + rivet libs directory)
>
> 2) if they're moved into /usr/lib manually apache fails with the same
> reason. ldd output is
> gershwin:~/Projects/rivet/1_0> ldd src/.libs/mod_rivet.so
> linux-gate.so.1 => (0xffffe000)
> libtcl8.4.so.0 => /usr/lib/libtcl8.4.so.0 (0xb7e93000)
> libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e8f000)
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d5e000)
> libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d39000)
> libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d27000)
> libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7cf9000)
> libdb-4.4.so => /usr/lib/libdb-4.4.so (0xb7bfd000)
> libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7bdd000)
> /lib/ld-linux.so.2 (0x80000000)
>
> I expect librivet and librivetparser to be listed there.
>
> -- Massimo
>
> Eckhard Lehmann wrote:
> >
> >> the question now is: where mod_rivet.so expects to find librivet.so and
> >> librivetparser.so? /usr/lib didn't work and lib_libexecdir didn't
> >> work either... the latter is evaluated as /usr/share/rivet0.7.0
> >>
> >
> > The libraries must be on LD_LIBRARY_PATH - including the Tcl package
> > library (I think it's librivet.so). This should also be the library
> > where Rivet_Init is defined.
> >
> > You can do a simple test with all the libraries that are generated in
> > the rivet distribution: for every library, do
> > nm <path/to/library>
> >
> > and look where Rivet_Init is defined. This one must be on the dynamic
> > library load path (LD_LIBRARY_PATH or added through ldconfig).
> >
> >
> > Eckhard
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> > For additional commands, e-mail: rivet-dev-help@tcl.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: escape_string in 1_0
Posted by Massimo Manghi <ma...@biol.unipr.it>.
Thank you Eckhard,
I expect mod_rivet to be able to load the libraries if they are
in /usr/lib. This is at least a general assumption on Debian/Linux
and, for what I know, on every other Unix-like os.
I can see 2 problems with Rivet set up:
1) make install fails to actually copy the 2 libraries
(librivetparser.so,librivet.so)
in either /usr/lib or /usr/share/rivet0.7.0 (see src/Makefile.am):
for instance, when 'make install' attempts to install librivetparser.so
/usr/bin/install -c .libs/librivetparser.so /usr/lib
/usr/share/rivet0.7.0/librivetparser.so
/usr/bin/install: target `/usr/share/rivet0.7.0/librivetparser.so' is
not a directory
the form of the command 'install' is actually wrong (install <options>
<source> <dest. dir>).
It seems that lib_libexecdir is used by configure in order to establish
the target
for 'install'. But this symbol is a 2 directory list (apache libs
directory + rivet libs directory)
2) if they're moved into /usr/lib manually apache fails with the same
reason. ldd output is
gershwin:~/Projects/rivet/1_0> ldd src/.libs/mod_rivet.so
linux-gate.so.1 => (0xffffe000)
libtcl8.4.so.0 => /usr/lib/libtcl8.4.so.0 (0xb7e93000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e8f000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d5e000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d39000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d27000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7cf9000)
libdb-4.4.so => /usr/lib/libdb-4.4.so (0xb7bfd000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7bdd000)
/lib/ld-linux.so.2 (0x80000000)
I expect librivet and librivetparser to be listed there.
-- Massimo
Eckhard Lehmann wrote:
>
>> the question now is: where mod_rivet.so expects to find librivet.so and
>> librivetparser.so? /usr/lib didn't work and lib_libexecdir didn't
>> work either... the latter is evaluated as /usr/share/rivet0.7.0
>>
>
> The libraries must be on LD_LIBRARY_PATH - including the Tcl package
> library (I think it's librivet.so). This should also be the library
> where Rivet_Init is defined.
>
> You can do a simple test with all the libraries that are generated in
> the rivet distribution: for every library, do
> nm <path/to/library>
>
> and look where Rivet_Init is defined. This one must be on the dynamic
> library load path (LD_LIBRARY_PATH or added through ldconfig).
>
>
> Eckhard
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: escape_string in 1_0
Posted by Eckhard Lehmann <ec...@web.de>.
Am Freitag, den 15.12.2006, 16:30 +0100 schrieb Massimo Manghi:
> David Welton wrote:
> >> ok, I changed it by hand. 'svn diff' produces a patch quite similar
> >> to the one you passed me. I compiled and restarted apache
> >>
> >> Cannot load /home/manghi/Projects/rivet/1_0/src/.libs/mod_rivet.so
> >> into server:
> >> /home/manghi/Projects/rivet/1_0/src/.libs/mod_rivet.so: undefined
> >> symbol: Rivet_Init
> the question now is: where mod_rivet.so expects to find librivet.so and
> librivetparser.so? /usr/lib didn't work and lib_libexecdir didn't
> work either... the latter is evaluated as /usr/share/rivet0.7.0
The libraries must be on LD_LIBRARY_PATH - including the Tcl package
library (I think it's librivet.so). This should also be the library
where Rivet_Init is defined.
You can do a simple test with all the libraries that are generated in
the rivet distribution: for every library, do
nm <path/to/library>
and look where Rivet_Init is defined. This one must be on the dynamic
library load path (LD_LIBRARY_PATH or added through ldconfig).
Eckhard
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org