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.

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

On 01/06/07, BarryK <bkau...@gmail.com> wrote:

If you post the error message here, someone can probably help you
figure it out.  It's likely to be extremely minor.

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

Discovery is in the separate wvdialconf binary anyway.

Have fun,

Avery

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

On 01/06/07, Adam Williamson <awilliam...@mandriva.com> wrote:

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

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

On 6/2/07, BarryK <bkau...@gmail.com> wrote:

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

Yep, same system. Openssl is v0.9.8b -- but, wvdial compiles fine
against the shared libs, and no problem with openssl.

Correction to my earlier post, those undefined symbols are in /usr/
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.

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

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

On 03/06/07, BarryK <bkau...@gmail.com> wrote:

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...

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

On 03/06/07, BarryK <bkau...@gmail.com> wrote:

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...

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.

This is a totally different error.  Just take out the default
parameter at wvstringtable.cc:12.

Have fun,

Avery

On 6/4/07, Avery Pennarun <apenw...@gmail.com> wrote:

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...

--
http://pphaneuf.livejournal.com/

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>

signature.asc < 1K Download

Yes, yes it would.

It turns a compile-time failure into a run-time failure.

Cheers,
--
Simon Law                                 http://www.law.yi.org/~sfllaw/

signature.asc < 1K Download

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

On 05/06/07, BarryK <bkau...@gmail.com> wrote:

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.t...
- 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

wvdial-1.41-gcc4.0.diff 5K Download

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

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

On 07/06/07, BarryK <bkau...@gmail.com> wrote:

Thanks!

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

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)