Want compile wvstreams statically with wvdial
BarryK
live-CD) that loads totally into RAM. Programs are chosen that are
small, and we have been using wvdial v1.42 as it is so small. It works
for us, but we can't compile it anymore -- and I don't understand the
error message -- it's designed for an older C++ compiler.
Wvdial 1.42 is only 84K complete, whereas I have just compiled v1.56
and wvstreams v4.3 -- the executable and libraries total 1510KB! So, I
thought I would try to compile wvstreams statically into wvdial, but I
can't figure out how to do it.
In Puppy Linux we have our own discovery of the modem, so we don't
need any of that, all we need is a dialer, which is probably why the
v1.42 is still okay for us for modern pci and usb softmodems.
So, I was wondering if a wvdial developer would help us out and figure
out why it no longer compiles.
Alternatively, if there are pressing reasons why we should go for a
more recent version, would it be possible to have a configure option
to compile wvstreams statically with wvdial?
Even better would be a reduced wvdial that just does the dialing and
negotiating with the isp, etc., with all discovery stuff removed.
Is anyone interested in getting involved with any of this?
You can read about Puppy here: http://www.puppylinux.com, also
http://www.puppylinux.org
My developer blog: http://www.puppylinux.com/news/
Regards,
Barry Kauler
Avery Pennarun
> Hi, I a developer for Puppy Linux, which is a tiny distro (about 90MB
> live-CD) that loads totally into RAM. Programs are chosen that are
> small, and we have been using wvdial v1.42 as it is so small. It works
> for us, but we can't compile it anymore -- and I don't understand the
> error message -- it's designed for an older C++ compiler.
If you post the error message here, someone can probably help you
figure it out. It's likely to be extremely minor.
> Alternatively, if there are pressing reasons why we should go for a
> more recent version, would it be possible to have a configure option
> to compile wvstreams statically with wvdial?
I can't remember if libwvstreams compiles a .a file anymore - I
thought it did, but maybe it's not installed as part of the package.
Linking wvdial with the static wvstreams library should be very easy
to do. It may be as simple as:
- build wvstreams
- "rm *.so" in the wvstreams directory
- build wvdial
> Even better would be a reduced wvdial that just does the dialing and
> negotiating with the isp, etc., with all discovery stuff removed.
Discovery is in the separate wvdialconf binary anyway.
Have fun,
Avery
Adam Williamson
> > Alternatively, if there are pressing reasons why we should go for a
> > more recent version, would it be possible to have a configure option
> > to compile wvstreams statically with wvdial?
>
> I can't remember if libwvstreams compiles a .a file anymore - I
> thought it did, but maybe it's not installed as part of the package.
It comes out in our (Mandriva's) build:
libwvstreams4.3-devel-4.3-3mdv2008.0.i586.rpm
Files:
-rw-r--r-- root root 6872654 /usr/lib/libwvstreams.a
md5: 89adaee8e2a9d403dfc1effc44d1324f Color: 1
Class: ar archive with 32-bit ELF objects
Rather big, isn't it? Guess I should split it into a -static-devel
package...
--
adamw
Avery Pennarun
> -rw-r--r-- root root 6872654 /usr/lib/libwvstreams.a
> md5: 89adaee8e2a9d403dfc1effc44d1324f Color: 1
> Class: ar archive with 32-bit ELF objects
>
> Rather big, isn't it? Guess I should split it into a -static-devel
> package...
That's C++ debug info for you... big. I personally wouldn't bother
splitting into a separate -static-devel package if only developers
need to install the -devel package anyway... disk space is cheap :)
Have fun,
Avery
BarryK
> figure it out. It's likely to be extremely minor.
Heh, heh, yes, it is a simple matter of the final link step unable to
find symbols.
But I'm a scripting guy and my compiling knowledge is fairly basic and
I was unable
to figure out the solution.
I removed all the '.so' files beforehand and then ran 'make wvdial'
and got this:
linking wvdial...
/usr/lib/gcc/i486-t2-linux-gnu/3.4.4/../../../
libwvstreams.a(wvsslstream.o)(.text+0x26): In function
`WvSSLStream::printerr(WvFastString const&)':
crypto/wvsslstream.cc:177: undefined reference to `ERR_get_error'
/usr/lib/gcc/i486-t2-linux-gnu/3.4.4/../../../
libwvstreams.a(wvsslstream.o)(.text+0x2d):crypto/wvsslstream.cc:180:
undefined reference to `SSL_load_error_strings'
/usr/lib/gcc/i486-t2-linux-gnu/3.4.4/../../../
libwvstreams.a(wvsslstream.o)(.text+0x6c):crypto/wvsslstream.cc:183:
undefined reference to `ERR_error_string'
....and it continues on.
Could anyone advise me how to fix this? Those symbols are there, in /
usr/include/wvstreams.
Thanks for the responses to my first post.
Regards,
Barry Kauler
William Lachance
What version of OpenSSL do you have installed on your system? Are you
sure that the same version was installed both when you were building
wvstreams and when
you were building wvdial?
--
William Lachance
wrl...@gmail.com
BarryK
> sure that the same version was installed both when you were building
> wvstreams and when
> you were building wvdial?
Yep, same system. Openssl is v0.9.8b -- but, wvdial compiles fine
against the shared libs, and no problem with openssl.
BarryK
include/openssl/.
Just to clarify, I compiled wvstreams, then immediately compiled
wvdial, no problem. I then removed the shared libraries, leaving all
static, then tried to recompile wvdial, and I even expanded the
tarball again to ensure pristine source, but no go, the final link
fails. Somehow it can't find those symbols, whereas linking with the
shared libs does work.
BarryK
Ah ha! I did it! I did this:
# export LDFLAGS=-lssl
# make
Now, let's see what we end up with.... wvdial after stripping is 554KB
-- too big! (as I previously mentioned, v1.42 is only 85K)
Which brings me back to wvdial v1.42. This is what I get after running
make:
--> Making all in /mnt/hda3/sources/sources106/wvdial-1.42/src/
utils...
g++ $_R_CXXFLAGS -c wvstringtable.cc
In file included from wvstringtable.cc:7:
wvstringtable.h:17:1: pasting "~" and "WvStringList" does not give a
valid preprocessing token
wvstringtable.h:17:1: pasting "~" and "WvStringTable" does not give a
valid preprocessing token
wvstringtable.cc:12: error: default argument given for parameter 1 of
`WvString WvStringTable::join(const char*)'
wvstringtable.h:15: error: after previous specification in `WvString
WvStringTable::join(const char*)'
make[1]: *** [wvstringtable.o] Error 1
make: *** [subdirs] Error 2
...does this error message mean anything to anyone reading this? I
looked at the source, and the msg means absolutely nothing to me. Here
is utils/wvstringtable.h:
#ifndef __WVSTRINGTABLE_H
#define __WVSTRINGTABLE_H
#include "wvstring.h"
#include "wvhashtable.h"
DeclareWvTable2(WvString,
WvString join(const char *joinchars = " ");
);
#endif // __WVSTRINGTABLE_H
Regards,
Barry Kauler
Joe Mason
DeclareWvTable2 is a macro that expands to a full class definition for a
WvTable containing WvString's. (It's the kind of thing you'd do nowadays
with WvTable<WvString>.) It uses the ## oparator to concatenate strings
inside the preprocessor, so at some point in that macro (which is defined in
wvhashtable.h or some file included form it) it'll say something like "~ ##
WvStringList" to create the name of the destructor. Your compiler's choking
on that for some reason.
Joe
Avery Pennarun
> Ah ha! I did it! I did this:
> # export LDFLAGS=-lssl
> # make
Hmm, it's rather sad that linking any wvstreams application apparently
now sucks in a dependency on openssl, even though wvdial certainly
wouldn't use it for anything. Kind of strange...
> wvstringtable.h:17:1: pasting "~" and "WvStringList" does not give a
> valid preprocessing token
> wvstringtable.h:17:1: pasting "~" and "WvStringTable" does not give a
> valid preprocessing token
As Joe mentioned, this is a problem with more recent versions of gcc's
preprocessor. I'm not sure what the "strictly correct" behaviour is
here, but if I recall, the fix was to change something like
~##ClassName
to just
Avery Pennarun
> Ah ha! I did it! I did this:
> # export LDFLAGS=-lssl
> # make
Hmm, it's rather sad that linking any wvstreams application apparently
now sucks in a dependency on openssl, even though wvdial certainly
wouldn't use it for anything. Kind of strange...
> wvstringtable.h:17:1: pasting "~" and "WvStringList" does not give a
> valid preprocessing token
> wvstringtable.h:17:1: pasting "~" and "WvStringTable" does not give a
> valid preprocessing token
As Joe mentioned, this is a problem with more recent versions of gcc's
preprocessor. I'm not sure what the "strictly correct" behaviour is
here, but if I recall, the fix was to change something like
~##ClassName
to just
~ClassName
Or something like that. It'll be in both wvhashtable.h and wvlinklist.h.
> wvstringtable.cc:12: error: default argument given for parameter 1 of
> `WvString WvStringTable::join(const char*)'
> wvstringtable.h:15: error: after previous specification in `WvString
> WvStringTable::join(const char*)'
This is a totally different error. Just take out the default
parameter at wvstringtable.cc:12.
Have fun,
Avery
Pierre Phaneuf
> On 03/06/07, BarryK <bka...@gmail.com> wrote:
> > Ah ha! I did it! I did this:
> > # export LDFLAGS=-lssl
> > # make
>
> Hmm, it's rather sad that linking any wvstreams application apparently
> now sucks in a dependency on openssl, even though wvdial certainly
> wouldn't use it for anything. Kind of strange...
The monikers machinery would pull it in, "just in case" you get an
"ssl:" moniker request. Whereas before, it was only pulled in if you
actually had a WvSSLStream in your code...
William Lachance
>
> The monikers machinery would pull it in, "just in case" you get an
> "ssl:" moniker request. Whereas before, it was only pulled in if you
> actually had a WvSSLStream in your code...
Would the new XPLC-module loading code in the uniservice branch fix
this? If so, it may well be worth merging in.
--
William Lachance <wrl...@gmail.com>
Simon Law
Yes, yes it would.
It turns a compile-time failure into a run-time failure.
Cheers,
--
Simon Law http://www.law.yi.org/~sfllaw/
BarryK
> > valid preprocessing token
> > wvstringtable.h:17:1: pasting "~" and "WvStringTable" does not give a
> > valid preprocessing token
>
> As Joe mentioned, this is a problem with more recent versions of gcc's
> preprocessor. I'm not sure what the "strictly correct" behaviour is
> here, but if I recall, the fix was to change something like
>
> ~##ClassName
> to just
> ~ClassName
>
> Or something like that. It'll be in both wvhashtable.h and wvlinklist.h.
>
> > wvstringtable.cc:12: error: default argument given for parameter 1 of
> > `WvString WvStringTable::join(const char*)'
> > wvstringtable.h:15: error: after previous specification in `WvString
> > WvStringTable::join(const char*)'
>
> This is a totally different error. Just take out the default
> parameter at wvstringtable.cc:12.
Ok, I did all of that, and it works, or rather those files compiled.
Then it stops with this:
--> Making all in /mnt/hda3/sources/sources106/wvdial-1.42/src/
utils...
g++ $_R_CXXFLAGS -c wvstringtable.cc
g++ $_R_CXXFLAGS -c wvlinklist.cc
wvlinklist.cc: In member function `void WvList::SorterBase::rewind(int
(*)(const void*, const void*))':
wvlinklist.cc:76: error: ISO C++ forbids cast to non-reference type
used as lvalue
make[1]: *** [wvlinklist.o] Error 1
...this is very slow going. So far I've got 4 object files. I think
I'll just give up...
Regards,
Barry Kauler
Avery Pennarun
> ...this is very slow going. So far I've got 4 object files. I think
> I'll just give up...
But it's educational! Just think of the fringe benefits of learning
the nuances of different C++ compiler versions!
Okay, okay, you've guilted me into it. Attached is a patch to
wvdial-1.41.tar.gz (from
http://archive.debian.org/dists/potato/main/source/comm/wvdial_1.41.tar.gz
- I couldn't find any wvdial-1.42.tar.gz files in google, but this
patch will hopefully work in 1.42 too) that makes it compile on my
system, with gcc-3.3.6 or gcc-4.0. If you have a URL for the 1.42
source code, please post it here so google can find it.
It was a bit of a trip down memory lane... wvdial-1.41 was from
January 2000, shortly before NITI ever got financing, opened an
office, hired people, and so on. WvStreams was so small and simple
and innocent back then! And wvdial didn't even *include* the
ipstreams part of wvstreams at the time, so it definitely didn't link
in any unncessary bits by accident.
Have fun,
Avery
BarryK
> - I couldn't find any wvdial-1.42.tar.gz files in google, but this
> patch will hopefully work in 1.42 too) that makes it compile on my
> system, with gcc-3.3.6 or gcc-4.0. If you have a URL for the 1.42
> source code, please post it here so google can find it.
>
> It was a bit of a trip down memory lane... wvdial-1.41 was from
> January 2000, shortly before NITI ever got financing, opened an
> office, hired people, and so on. WvStreams was so small and simple
> and innocent back then! And wvdial didn't even *include* the
> ipstreams part of wvstreams at the time, so it definitely didn't link
> in any unncessary bits by accident.
It compiles!
Thanks very much for helping me out. I made an announcement and
acknowledgement here:
http://www.puppylinux.com/news/
...note my query about v1.41 versus 1.42.
Regards,
Barry Kauler
BarryK
> > patch will hopefully work in 1.42 too) that makes it compile on my
> > system, with gcc-3.3.6 or gcc-4.0. If you have a URL for the 1.42
> > source code, please post it here so google can find it.
The 1.42 source is here:
http://puptrix.org/sources/alphabetical/w/
Note, I tried to apply the patch to 1.42, by replacing all occurences
of 'wvdial-1.41' with 'wvdial-1.42' but it didn't work.
Regards,
Barry Kauler
Avery Pennarun
> The 1.42 source is here:
> http://puptrix.org/sources/alphabetical/w/
Thanks!
> Note, I tried to apply the patch to 1.42, by replacing all occurences
> of 'wvdial-1.41' with 'wvdial-1.42' but it didn't work.
The correct way to install a patch like this is:
tar -xzvf wvdial-1.41.tar.gz
cd wvdial-1.41
patch -p1 </tmp/whatever.diff
Note the "-p1", which makes patch drop the first element of the path.
That's almost always what you want, since the directory name in the
patch is almost never what you named it.
I'll try the patch again with 1.42 when I get the chance, but I can't right now.
Have fun,
Avery
BarryK
Okay, I figured it out. The patch didn't quite work, but I was able to
manually fix the places where it failed by examining the '.rej' files.
Almost there. I still get one error, that I don't understand.
There are some significant diffrences from 1.41 -- for example, it has
'wvstringtable.cc', which 1.41 doesn't have. There was a bug in
'wvstringtable.cc' that was already discussed earlier in this thread,
so I fixed that and put my initials 'BK' at the change. But still one
outstanding error.
Anyway, I have uploaded the patched source to here, if anyone wants to
run 'make' on it and fix the error:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/
(file is wvdial-1.42-patched0.tar.gz)