libstrophe building issues
Dawid Ciężarkiewicz (dpc.ucore.info)
I've got some queries/bug regarding current git HEAD version.
* bootstraph.sh contains full path to aclocal - this seems it would be
better and more generic if it was just a "aclocal".
* on some old Debian autoconf fails with:
Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in
`configure.ac'
fix (configure.ac):
AC_PROG_CC
AC_PROG_RANLIB
+AM_PROG_CC_C_O
in configure.ac
* make install does not copy "strophe.h" to $prefix/include/. Is there
any reason or is it a bug?
Regards,
Dawid
Jack Moffitt
>
> * bootstraph.sh contains full path to aclocal - this seems it would be
> better and more generic if it was just a "aclocal".
The line in question is:
aclocal -I /usr/local/share/aclocal
which just adds an extra include path. Does that break things? This
used to be necessary on OS X, and my understanding was that Linux
systems wouldn't have any problems with it.
> * on some old Debian autoconf fails with:
> Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in
> `configure.ac'
>
> fix (configure.ac):
> AC_PROG_CC
> AC_PROG_RANLIB
> +AM_PROG_CC_C_O
I guess there was some automake change that necessitated this be
explicit? I know this used to build fine :) Definitely looks like the
docs say its required though. I'll fix it up.
> in configure.ac
>
> * make install does not copy "strophe.h" to $prefix/include/. Is there
> any reason or is it a bug?
That's probably a bug. Can you file a ticket? I'll get that patched up.
jack.
Dawid Ciężarkiewicz
>> * bootstraph.sh contains full path to aclocal - this seems it would be
>> better and more generic if it was just a "aclocal".
>
> The line in question is:
> aclocal -I /usr/local/share/aclocal
>
> which just adds an extra include path. Does that break things? This
> used to be necessary on OS X, and my understanding was that Linux
> systems wouldn't have any problems with it.
I'm afraid they do:
dpc@spinlock:libstrophe$ ./bootstrap.sh
aclocal: couldn't open directory `/usr/local/share/aclocal': No such
file or directory
configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
Makefile.am:15: BUILD_EXPAT does not appear in AM_CONDITIONAL
Makefile.am:27: PARSER_EXPAT does not appear in AM_CONDITIONAL
Makefile.am: installing `./depcomp'
/usr/share/automake-1.11/am/depend2.am: am__fastdepCC does not appear
in AM_CONDITIONAL
/usr/share/automake-1.11/am/depend2.am: The usual way to define
`am__fastdepCC' is to add `AC_PROG_CC'
/usr/share/automake-1.11/am/depend2.am: to `configure.ac' and run
`aclocal' and `autoconf' again.
/usr/share/automake-1.11/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.11/am/depend2.am: The usual way to define
`AMDEP' is to add one of the compiler tests
/usr/share/automake-1.11/am/depend2.am: AC_PROG_CC, AC_PROG_CXX,
AC_PROG_CXX, AC_PROG_OBJC,
/usr/share/automake-1.11/am/depend2.am: AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
/usr/share/automake-1.11/am/depend2.am: to `configure.ac' and run
`aclocal' and `autoconf' again.
configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:7: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:39: error: possibly undefined macro: AM_CONDITIONAL
dpc@spinlock:libstrophe$ sed -ie 's#aclocal -I
/usr/local/share/aclocal#aclocal#g' bootstrap.sh
autoconfdpc@spinlock:libstrophe$ ./bootstrap.sh
configure.ac:2: installing `./install-sh'
configure.ac:2: installing `./missing'
dpc@spinlock:libstrophe$
>> * make install does not copy "strophe.h" to $prefix/include/. Is there
>> any reason or is it a bug?
>
> That's probably a bug. Can you file a ticket? I'll get that patched up.
I'd love to but I don't have permissions.
I mean... I try to login via OpenID because I don't have any account
and I can't see any "Register" link.
But when I return from my openid provider I get:
Oops…
Trac detected an internal error:
SMTPSenderRefused: (429, '4.0.0 Your account has expired - please
renew at the control panel at http://control.authsmtp.com/renew/',
u'"Strophe Trac" <co...@stanziq.com>')
There was an internal error in Trac. It is recommended that you inform
your local Trac administrator and give him all the information he
needs to reproduce the issue.
To that end, you could a ticket.
The action that triggered the error was:
GET: /
TracGuide — The Trac User and Administration Guide
And I'm not permitted to creat new tickets.
So - no cake. :/
I'm developing my little toy project and I find libstrophe a perfect
example of how the true C library should look like. I'll let you know
if I find any further problems. I see that the autotools build system
is quite recent.
--
http://dpc.ucore.info
Jack Moffitt
Sorry. I'll look into that and see if we can't get those kinks worked
out. We recently changed the auth system because spammers were taking
over the wiki.
> I'm developing my little toy project and I find libstrophe a perfect
> example of how the true C library should look like. I'll let you know
> if I find any further problems. I see that the autotools build system
> is quite recent.
Thanks. The HEAD revision in Git should have all your suggested
changes and the header file fix. Please let me know if you still have
any issues.
jack.
Ilya Braude
Dawid Ciężarkiewicz wrote:
> On Wed, Jun 9, 2010 at 5:22 PM, Jack Moffitt <ja...@collecta.com> wrote:
>
>
>>> * bootstraph.sh contains full path to aclocal - this seems it would be
>>> better and more generic if it was just a "aclocal".
>>>
>> The line in question is:
>> aclocal -I /usr/local/share/aclocal
>>
>> which just adds an extra include path. Does that break things? This
>> used to be necessary on OS X, and my understanding was that Linux
>> systems wouldn't have any problems with it.
>>
>
> I'm afraid they do:
>
I can confirm. I had to change this to my local path
(/usr/share/aclocal) when compiling on Ubuntu.
On a related note, is it really necessary to run bootstrap.sh as opposed
to just including the result in the distribution?
Normally software is distributed with the configure script already
generated. And when I was cross-compiling for OpenWRT, I only used the
result of running bootstrap.sh in the cross-compiler environment.
But I don't know much about autoconf, so I might very well be missing
something here.
Ilya
Jack Moffitt
> just including the result in the distribution?
> Normally software is distributed with the configure script already
> generated. And when I was cross-compiling for OpenWRT, I only used the
> result of running bootstrap.sh in the cross-compiler environment.
> But I don't know much about autoconf, so I might very well be missing
> something here.
bootstrap.sh is only for people building from Git. I haven't made a
release of libstrophe in some time, so there isn't a recent copy with
prebuilt configure. I'll put that on my todo list to do a new release.
jack.
Dawid Ciężarkiewicz
> Thanks. The HEAD revision in Git should have all your suggested
> changes and the header file fix. Please let me know if you still have
> any issues.
I'm hacking around support for --with-libxml2 / builtin expat.
First:
After compiling with-libxml2 ./example/bot didn't worked. It got
parsing error. We may investigate further if you'd like.
Second:
The part of -with-libxml2 presents non-standard behavior.
AC_ARG_WITH([libxml2],-
[AS_HELP_STRING([--with-libxml2], [use libxml2 for XML parsing])],
[with_libxml2=check],
[with_libxml2=no])
if test "x$with_libxml2" != xno; then
PKG_CHECK_MODULES([libxml2], [libxml-2.0 >= 2.7],
[with_libxml2=yes],-
[AC_MSG_ERROR([couldn't find libxml2])])
else
AC_CHECK_FUNCS(memmove)
AC_C_BIGENDIAN([byteorder=1234], [byteorder=4321], [], [])
fi
The [is-present] condition ([with_libxml2=check]) will be execute when
./configure was called with any of:
--with-libxml2
--without-libxml2
I guess the intention was only to support "--with-libxml2", but this
would be much better if:
--with-libxml2 would force to use libxml2 (and error if it is not
present in the system)
--without-libxml2 would force not to use libxml2
no such argument would do the default (check / not use)
Third:
Could you help me with understanding:
AC_C_BIGENDIAN([byteorder=1234], [byteorder=4321], [], [])
when libxml2 is being used?
Fourth (and most important):
How do I (as a application developer) am to handle detection of
libstrophe builtin vs libxml2 ? If the libexapt would be really
*builtin* then I wouldn't have to add -lexpat when compiling my
program. I guess libexpat.a should:
a) get included into libstrophe.a
b) be dynamically linked for libstrophe.so if dynamic version of
libstrophe is available
Fifth:
Why builtin expat instead of system-wide expat?
I appreciate your feedback. :)
--
http://dpc.ucore.info
Jack Moffitt
> After compiling with-libxml2 ./example/bot didn't worked. It got
> parsing error. We may investigate further if you'd like.
Please do. It should work fine, but I haven't been using libstrophe a
lot myself lately, though I do have a new project I'm thinking about
using it on.
> Second:
> The part of -with-libxml2 presents non-standard behavior.
...
> I guess the intention was only to support "--with-libxml2", but this
> would be much better if:
> --with-libxml2 would force to use libxml2 (and error if it is not
> present in the system)
> --without-libxml2 would force not to use libxml2
> no such argument would do the default (check / not use)
If you have a quick patch for that, I'd be happy to commit it. I
assume we just need another bit of stuff in the else block.
> Third:
> Could you help me with understanding:
> AC_C_BIGENDIAN([byteorder=1234], [byteorder=4321], [], [])
> when libxml2 is being used?
The byteorder thing is for expat I think. This is usually done by
expat's configure, but since we don't run that, I do it here. There
are a few of these build parameters that the code expects to be set.
If it's doing it in libxml2 stuff, that's probably a bug.
> Fourth (and most important):
> How do I (as a application developer) am to handle detection of
> libstrophe builtin vs libxml2 ? If the libexapt would be really
> *builtin* then I wouldn't have to add -lexpat when compiling my
> program. I guess libexpat.a should:
> a) get included into libstrophe.a
> b) be dynamically linked for libstrophe.so if dynamic version of
> libstrophe is available
Why do you care what XML library it is built with? It doesn't affect
you at all as an application developer. All the XML bits are
completely abstracted within Strophe, and you have no access to them
(not even to the abstraction layer that libstrophe uses).
Do you mean, how do you know which to link to? I didn't think I was
building dynamically linked libraries, so you'll never have to worry
about that either. I guess I need to figure out some way to have
expat or libxml2 exist inside libstrophe.a? Is that possible?
> Fifth:
> Why builtin expat instead of system-wide expat?
Building random dependencies can be a pain in the ass, especially on
Windows. My primarily goal when building libstrophe was originally to
have it have zero dependencies so that it was trivial to use.
Later on, I thought I could use the XPath stuff in libxml2 for stanza
matching, and wrote support for that. When it turned out I couldn't
make use of XPath after all, I made a simple abstraction layer and
allowed people to choose the XML parsing engine at build time.
jack.
Dawid Ciężarkiewicz
>> First:
>> After compiling with-libxml2 ./example/bot didn't worked. It got
>> parsing error. We may investigate further if you'd like.
>
> Please do. It should work fine, but I haven't been using libstrophe a
> lot myself lately, though I do have a new project I'm thinking about
> using it on.
I will provide more details tomorrow.
>> Second:
>> The part of -with-libxml2 presents non-standard behavior.
> ...
>> I guess the intention was only to support "--with-libxml2", but this
>> would be much better if:
>> --with-libxml2 would force to use libxml2 (and error if it is not
>> present in the system)
>> --without-libxml2 would force not to use libxml2
>> no such argument would do the default (check / not use)
>
> If you have a quick patch for that, I'd be happy to commit it. I
> assume we just need another bit of stuff in the else block.
Just as the first.
>> Fourth (and most important):
>> How do I (as a application developer) am to handle detection of
>> libstrophe builtin vs libxml2 ? If the libexapt would be really
>> *builtin* then I wouldn't have to add -lexpat when compiling my
>> program. I guess libexpat.a should:
>> a) get included into libstrophe.a
>> b) be dynamically linked for libstrophe.so if dynamic version of
>> libstrophe is available
>
> Why do you care what XML library it is built with? It doesn't affect
> you at all as an application developer. All the XML bits are
> completely abstracted within Strophe, and you have no access to them
> (not even to the abstraction layer that libstrophe uses).
>
> Do you mean, how do you know which to link to? I didn't think I was
> building dynamically linked libraries, so you'll never have to worry
> about that either. I guess I need to figure out some way to have
> expat or libxml2 exist inside libstrophe.a? Is that possible?
It does. I need to add -lexpat to my application if libstrophe was
built for expat and -lxml2 if for libxml2.
I'm quite sure you can easily merge *.a files as they are only
archives of *.o files. ar tool should handle this.
>> Fifth:
>> Why builtin expat instead of system-wide expat?
>
> Building random dependencies can be a pain in the ass, especially on
> Windows. My primarily goal when building libstrophe was originally to
> have it have zero dependencies so that it was trivial to use.
>
> Later on, I thought I could use the XPath stuff in libxml2 for stanza
> matching, and wrote support for that. When it turned out I couldn't
> make use of XPath after all, I made a simple abstraction layer and
> allowed people to choose the XML parsing engine at build time.
Oh. So you're Windows user. Well - developing on/for Windows is PITA.
From my perspective the best way to handle all this is to build
dynamic library from libstrophe and use standard expat/libxml2
versions bundled/installed with the system. Dynamically loaded
libraries contain the information on what they depend on and this is
handled with grace. That would solve the forth problem as well.
Regards,
Dawid
George Morgan
> You received this message because you are subscribed to the Google Groups "Strophe" group.
> To post to this group, send email to str...@googlegroups.com.
> To unsubscribe from this group, send email to strophe+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/strophe?hl=en.
>
>
Oooh, so sorry I haven't posted some patches and started a discussion
related to this long ago. These were all issues that I had to resolve
with using libstrophe and I created a patch that my top level build
system accounts for. I need to see if I made this an RPM (I'm
developing on RHEL5). If so I can probably contribute a spec file
too. These are the issues I resolved in my patch IIRC:
1) Install of header files
2) aclocal fix for linux
3) libxml2 related fix for configure.ac?
4) Automake fix discussed above (adding the AM_PROG_CC_C_O or whatever)
5) Fix for parser_feed() related to libxml2 or libexpat (can't
remember which one).
6) Add prototypes for JID processing functions so external programs
can use these to strophe.h
7) Multi-thread safe changes for xmpp_send() to protect send queue
from interleaved access by multiple threads.
8) Maybe some memory leak related fixes? (I ran my application
through valgrind and might have found some leaks in libstrophe?)
---- other stuff??? ----
I'll see if I can post my patch tomorrow and also figure out what
version it is against. Obviously my changes need to be tested in
other OSes...
--
George Morgan
Dawid Ciężarkiewicz
> Oooh, so sorry I haven't posted some patches and started a discussion
> related to this long ago. These were all issues that I had to resolve
> with using libstrophe and I created a patch that my top level build
> system accounts for. I need to see if I made this an RPM (I'm
> developing on RHEL5). If so I can probably contribute a spec file
> too. These are the issues I resolved in my patch IIRC:
>
> 1) Install of header files
> 2) aclocal fix for linux
> 3) libxml2 related fix for configure.ac?
> 4) Automake fix discussed above (adding the AM_PROG_CC_C_O or whatever)
> 5) Fix for parser_feed() related to libxml2 or libexpat (can't
> remember which one).
> 6) Add prototypes for JID processing functions so external programs
> can use these to strophe.h
> 7) Multi-thread safe changes for xmpp_send() to protect send queue
> from interleaved access by multiple threads.
> 8) Maybe some memory leak related fixes? (I ran my application
> through valgrind and might have found some leaks in libstrophe?)
> ---- other stuff??? ----
>
> I'll see if I can post my patch tomorrow and also figure out what
> version it is against. Obviously my changes need to be tested in
> other OSes...
>
Haha. I've wanted 6 as well.
Please post your patches. I'll be glad to apple and test with them.
George Morgan
> You received this message because you are subscribed to the Google Groups "Strophe" group.
> To post to this group, send email to str...@googlegroups.com.
> To unsubscribe from this group, send email to strophe+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/strophe?hl=en.
>
>
Here is the patch against an older version from git... The latest
files from git appear to include the configure.ac fix (AM_PROG_CC_C_O)
and maybe the bootstrap.sh fix and maybe the includes fix. I did it
differently...it is up to someone who knows more about how
automake/autoconf work to figure out which is more correct. Oh, I
also modified the CFLAGS to use -fPIC to make the security stuff in
RHEL happy. (avoiding text relocations)
Ok, notes for the patch from the list above...
1) Install of header files
Need to decide if my way or way in latest GIT source is more correct.
2) aclocal fix for linux
Need to test on other OSes/find a OS agnostic fix.
3) libxml2 related fix for configure.ac?
I don't see this in the patch. I'd love to be able to select between
external libxml2 and external libexpat. I never got the files
necessary to use internal libexpat (this needs to be finally cleaned
up)
4) Automake fix discussed above (adding the AM_PROG_CC_C_O or whatever)
Same change appears in the latest from GIT I believe.
5) Fix for parser_feed() related to libxml2 or libexpat (can't
remember which one).
Fix is for libxml2 in parser_feed()
6) Add prototypes for JID processing functions so external programs
can use these to strophe.h
yep, its in there, not in GIT yet.
7) Multi-thread safe changes for xmpp_send() to protect send queue
from interleaved access by multiple threads.
Haven't tested this rigorously but I think it is working pretty good
because before I made this change I was definitely getting things hung
up and haven't seen these symptoms since.
8) Maybe some memory leak related fixes? (I ran my application
through valgrind and might have found some leaks in libstrophe?)
I don't think I found any memory leaks in libstrophe to fix. Although
I do remember looking :-)
--
George Morgan
Dawid Ciężarkiewicz
Sorry for delay.
I've cloned clean version of libstrophe from mainline repo and spent
some time working on problems I've described.
http://github.com/dpc/libstrophe/commits/master
Basically I've :
* rewritten autotools scripts to build self-contained dynamic versions
of library
* made libxml2 the default and --with --without should work as expected now
* improved few minor things that I've noticed
Using libxml2 crashes for me (instead of parsing errors) so I will
dive into gdb soon.
George Morgan
> Hi again,
>
> Sorry for delay.
>
> I've cloned clean version of libstrophe from mainline repo and spent
> some time working on problems I've described.
>
> http://github.com/dpc/libstrophe/commits/master
>
> Basically I've :
> * rewritten autotools scripts to build self-contained dynamic versions
> of library
> * made libxml2 the default and --with --without should work as expected now
> * improved few minor things that I've noticed
That's great. I just didn't know enough about autotools to fix up the
scripts. I had been wanting to change it to create dynamic versions
but didn't have the experience with autotools to get it to work.
> Using libxml2 crashes for me (instead of parsing errors) so I will
> dive into gdb soon.
Did you try the change in the patch that fixes up libxml2 supposedly?
I don't remember it crashing but it definitely did something that it
shouldn't have in the version I had.
> Regards,
> Dawid
> --
> http://dpc.ucore.info
>
> --
> You received this message because you are subscribed to the Google Groups "Strophe" group.
> To post to this group, send email to str...@googlegroups.com.
> To unsubscribe from this group, send email to strophe+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/strophe?hl=en.
--
George Morgan
Dawid Ciężarkiewicz
However it does not change the segfault.
See the backtrace:
dpc@stallman2:xmppconsole$ gdb xmppconsole
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/dpc/lab/xmppconsole/xmppconsole...done.
(gdb) r
Starting program: /home/dpc/lab/xmppconsole/xmppconsole
Start.
> /connect b...@test.server password
Connecting as b...@test.server.
Connection failed.
Disconnected.
> /debug
> /connect b...@test.server password
Connecting as b...@ucore.info.
sock_connect to xmpp-server.l.google.com:5222 returned 5
attempting to connect to xmpp-server.l.google.com
connection successful
SENT: <?xml version="1.0"?><stream:stream to="test.server"
xml:lang="en" version="1.0" xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">
RECV: <stream:stream from='test.server' id='4A453494DA26C2F1'
version='1.0' xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'>
RECV: <stream:features><starttls
xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>X-GOOGLE-TOKEN</mechanism></mechanisms></stream:features>
>
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff723a7d6 in memcpy () from /lib/libc.so.6
(gdb) where
#0 0x00007ffff723a7d6 in memcpy () from /lib/libc.so.6
#1 0x00007ffff6ba5d04 in ?? () from /usr/lib/libcrypto.so.0.9.8
#2 0x00007ffff6ba71a7 in RAND_poll () from /usr/lib/libcrypto.so.0.9.8
#3 0x00007ffff6ba6605 in ?? () from /usr/lib/libcrypto.so.0.9.8
#4 0x00007ffff6ba5ac6 in ?? () from /usr/lib/libcrypto.so.0.9.8
#5 0x00007ffff79adc56 in SSL_CTX_new () from /usr/lib/libssl.so.0.9.8
#6 0x00007ffff7bda77d in tls_new (ctx=0x635e10, sock=5) at src/tls_openssl.c:68
#7 0x00007ffff7bcffe4 in _auth (conn=0x639d90) at src/auth.c:467
#8 0x00007ffff7bd10cf in _handle_features (conn=0x639d90,
stanza=<value optimized out>, userdata=<value optimized out>)
at src/auth.c:236
#9 0x00007ffff7bd3bc2 in handler_fire_stanza (conn=0x639d90,
stanza=0x63b820) at src/handler.c:109
#10 0x00007ffff7bd238a in _handle_stream_stanza (stanza=0x63b820,
userdata=<value optimized out>) at src/conn.c:759
#11 0x00007ffff7bda9a5 in _end_element (userdata=0x636050, name=<value
optimized out>) at src/parser_libxml2.c:117
#12 0x00007ffff6ead655 in ?? () from /usr/lib/libxml2.so.2
#13 0x00007ffff6eba455 in ?? () from /usr/lib/libxml2.so.2
#14 0x00007ffff6ebb13b in xmlParseChunk () from /usr/lib/libxml2.so.2
#15 0x00007ffff7bd3046 in xmpp_run_once (ctx=0x635e10, timeout=<value
optimized out>) at src/event.c:273
#16 0x0000000000401f99 in net_nonblock_handle () at src/net.c:206
#17 0x000000000040180c in main () at src/main.c:20
uid and password are bogus.
I guess same panic happens with bot example.
BTW.
I've replaced all
#include <strophe.h>
with:
#include "strophe.h"
<> makes gcc use system headers first, while for building the local
one should be used.
Dawid Ciężarkiewicz
--
http://dpc.ucore.info
Dawid Ciężarkiewicz
--
http://dpc.ucore.info
George Morgan
library. I've got an application that I'm about ready to deliver to
my customer which uses the C library and the javascript.
Personally I'm very thankful you have worked on the autotools scripts
and the package config. I hope to take a look at it sometime soon.
2010/7/28 Dawid Ciężarkiewicz <d...@ucore.info>:
Dawid Ciężarkiewicz
George Morgan
discussion specific to the non-Javascript library. I think Jack
originally kept them together because he was hoping that if a feature
was added to the Javascript it would also be added to the C/C++ so
they would mirror each other. (totally a guess on my part) This is
still a good goal on some level but I'm wondering as far as the
Javascript has come who would put in the work to keep them synced. I
happen to be using both in the same project but I fear I may be the
only one.
2010/7/29 Dawid Ciężarkiewicz <d...@ucore.info>:
Jack Moffitt
> discussion specific to the non-Javascript library. I think Jack
> originally kept them together because he was hoping that if a feature
> was added to the Javascript it would also be added to the C/C++ so
> they would mirror each other. (totally a guess on my part) This is
> still a good goal on some level but I'm wondering as far as the
> Javascript has come who would put in the work to keep them synced. I
> happen to be using both in the same project but I fear I may be the
> only one.
If you guys think a segregated group would be useful, I'm happy to set one up.
jack.
Dawid Ciężarkiewicz (ucore.info)
> If you guys think a segregated group would be useful, I'm happy to set one up.
Yes, please do. :)
George Morgan
Dawid, where's the latest version of the libstrophe code? I pulled down the latest from "git" but I'm not seeing the patches integrated, etc. I still need to read up some more to see how development with "git" is accomplished...I've only ever used it to pull down copies of repos.
--
You received this message because you are subscribed to the Google Groups "Strophe" group.
To post to this group, send email to str...@googlegroups.com.
To unsubscribe from this group, send email to strophe+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/strophe?hl=en.
--
George Morgan
Dan
grabbed the latest code from git. The README.txt says to run scons.
but there is no SConstruct file. Running bootstrap.sh results in the
following and nothing built:
[dan@intranet libstrophe]$ ./bootstrap.sh
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
Makefile.am: installing `./compile'
Makefile.am: installing `./depcomp'
Makefile.am:22: `libstrophe_a_include_HEADERS' is used but
`libstrophe_a_includedir' is undefined
I'm trying to build on CentOS 5.5
George Morgan
./bootstrap.sh
./configure
make
make install <<< This is optional
I'm thinking there is a newer version of the code with support for building a shared library out there somewhere. Dawid was working on this but I haven't seen the fruits of his labor yet...
--
You received this message because you are subscribed to the Google Groups "Strophe" group.
To post to this group, send email to str...@googlegroups.com.
To unsubscribe from this group, send email to strophe+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/strophe?hl=en.
--
George Morgan
pitulloz
makefile.in not found. I install libtool, libssl, and check package
for dependency. Anyone can provide running configure file?
wimme
Should work on Centos to.
diffile Makefile.am
3c3
< CFLAGS = -g -Wall
---
> AM_CFLAGS = -g -Wall
22a23
> libstrophe_a_includedir = $(top_srcdir)
On line 3 I changed CFLAGS to AM_CFLAGS
On line 22 I added
libstrophe_a_includedir = $(top_srcdir)
i used ./configure --with-libxml2
everything compiles ok
> > .
Dawid Ciężarkiewicz (ucore.info)
> Did the new group get created?
>
> Dawid, where's the latest version of the libstrophe code? I pulled down the
> latest from "git" but I'm not seeing the patches integrated, etc. I still
> need to read up some more to see how development with "git" is
> accomplished...I've only ever used it to pull down copies of repos.
Hi,
Sorry for the delay -- I was on holidays.
Everything I do I push here (notice: this is github WWW, not a git url):
http://github.com/dpc/libstrophe/