FreeBSD support

[goodmanbeats]

Hello all,

I sent an email to the support _at_ avast .com address today (mentioned in the README of the Linux version Avast), then later read in the demo license email that this address is unmonitored.

So, my problem is, I would happily use Avast for mail scanning purposes on multiple machines, but the available binaries are compiled on FreeBSD version 4. The current stable version of FreeBSD is 7.1. The libc_r library, which avast is linked to dynamically, has been changed to libpthread years ago. I tried to make avast running by compiling a libc_r for FreeBSD7, but it does not work, if one builds a libc_r.so.7 and links it to libc_r.so.4, the avastd starts listening to sockets, etc, but when the avastcmd or avastlite scanner is invoked, or the avastd socket is used, nothing happens, the applications just hang forever.

Is there any hope for a new binary build soon?

[zilog]

Hello all,

I sent an email to the support _at_ avast .com address today (mentioned in the README of the Linux version Avast), then later read in the demo license email that this address is unmonitored.

So, my problem is, I would happily use Avast for mail scanning purposes on multiple machines, but the available binaries are compiled on FreeBSD version 4. The current stable version of FreeBSD is 7.1. The libc_r library, which avast is linked to dynamically, has been changed to libpthread years ago. I tried to make avast running by compiling a libc_r for FreeBSD7, but it does not work, if one builds a libc_r.so.7 and links it to libc_r.so.4, the avastd starts listening to sockets, etc, but when the avastcmd or avastlite scanner is invoked, or the avastd socket is used, nothing happens, the applications just hang forever.

Is there any hope for a new binary build soon?

Hallo,
yes, that's the infamous FreeBSD-threadlibrary hell. There were *MANY* threading library candidates used on FreeBSD in the past few years (libthr, libkse, libc_r, libpthread), all claimed to be interface-compatible, and thus, dependency-issues could be usually solved using /etc/libmap.conf aliases (and in the fact, this approach was usually used/recommended).

Btw. which one of those four libraries is the "recommended one" now, is a question - probably not libpthread, but libthr.
Have a look here: http://roy.marples.name/node/332

Anyway, there are two latest builds, so let's try to run them using /etc/libmap.conf, available here:

http://public.avast.com/~cimbal/BSD4/libavastengine-4.7.5-i586.tar.gz
http://public.avast.com/~cimbal/BSD4/avast4server-3.1.5-i586.tar.gz
http://public.avast.com/~cimbal/BSD5/libavastengine-4.7.5-i586.tar.gz
http://public.avast.com/~cimbal/BSD5/avast4server-3.1.5-i586.tar.gz

In the case of no success, we'll make extra build for FreeBSD7, but ... who knows, which threading model will be the new default in FreeBSD8

regards,
PC

[goodmanbeats]

Hello,

Thank you for the quick answer. I did not find links to these binaries on the Avast web site.

I tried both versions, starting with the libs and app built for FreeBSD5. No luck.

I ended up always with:
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by
/usr/lib/libavastengine-4.so.7 not found

and i have no libpthread libs on my system, just symlinks to libthr (which needed to be compatible with lpthread, but it is not.)

The version compiled for FreeBSD4 acts particularly like the old version i was trying very first, it simply hangs. the shmprobe in its installer simply starts using 99.7% CPU. I tried overwriting the libavast but the best I could reach is a

Code: [Select]

root@Merlin# avastcmd                                               
avastcmd: can not initialize avast! engine: Cannot allocate memory
How can we move forward with that?

By the way, FreeBSD developers pretend to use libthr from 6.x... maybe until forever, but who knows..

http://bugs.gentoo.org/192711

[goodmanbeats]

I tried one more thing, installed the compat5x and compat6x libs, and set up libmap with these.

effect:


/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"

[zilog]

Hello,

Thank you for the quick answer. I did not find links to these binaries on the Avast web site.

I tried both versions, starting with the libs and app built for FreeBSD5. No luck.

I ended up always with:
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by
/usr/lib/libavastengine-4.so.7 not found

and i have no libpthread libs on my system, just symlinks to libthr (which needed to be compatible with lpthread, but it is not.)

The version compiled for FreeBSD4 acts particularly like the old version i was trying very first, it simply hangs. the shmprobe in its installer simply starts using 99.7% CPU. I tried overwriting the libavast but the best I could reach is a

Code: [Select]

root@Merlin# avastcmd                                               
avastcmd: can not initialize avast! engine: Cannot allocate memory
How can we move forward with that?

By the way, FreeBSD developers pretend to use libthr from 6.x... maybe until forever, but who knows..

http://bugs.gentoo.org/192711

Hallo,
but, have you tried mapping via /etc/libmap.conf (not via pure symlinks) here? It's the right mechanism (not sym-linking, although this was used too).
http://bsdtips.utcorp.net/mediawiki/index.php/Do_not_symlink_missing_shared_libraries

I simply don't believe, that library X was replaced by X+1, with a lack of interface-functionality. But, from the past, there were also FreeBSD releases with totally crippled threading environment, preventing all 3rd party apps from running on them... With 5.3, we decided to link to libpthread, because libc_r was presented as obsolete, have a  look here: http://www.freebsd.org/releases/5.3R/errata.html

sigh, four threading libs, one less compatible than another, we'll have to create another cross-compiling chain for the 7.0, as it seems .

regards,
pc

[goodmanbeats]

Hello,

Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.

Code: [Select]

lrwxr-xr-x  1 root  wheel   8 Jun 20  2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x  1 root  wheel   9 Jun 20  2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  10 Jun 20  2008 /usr/lib/libpthread_p.a -> libthr_p.a

I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.

The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found

error.

If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.

I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.

I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it

Thanks,

Daniel

[zilog]

Hello,

Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.

Code: [Select]

lrwxr-xr-x  1 root  wheel   8 Jun 20  2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x  1 root  wheel   9 Jun 20  2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  10 Jun 20  2008 /usr/lib/libpthread_p.a -> libthr_p.a

I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.

The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found

error.

If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.

I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.

I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it

Thanks,

Daniel

Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically . Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 .

regards,
pc

[zilog]

Hello,

Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.

Code: [Select]

lrwxr-xr-x  1 root  wheel   8 Jun 20  2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x  1 root  wheel   9 Jun 20  2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  10 Jun 20  2008 /usr/lib/libpthread_p.a -> libthr_p.a

I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.

The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found

error.

If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.

I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.

I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it

Thanks,

Daniel

Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically . Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 .

regards,
pc

btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).

also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).

regards,
pc

[williamXP]

Hello,

Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.

Code: [Select]

lrwxr-xr-x  1 root  wheel   8 Jun 20  2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x  1 root  wheel   9 Jun 20  2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  10 Jun 20  2008 /usr/lib/libpthread_p.a -> libthr_p.a

I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.

The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found

error.

If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.

I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.

I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it

Thanks,

Daniel

Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically . Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 .

regards,
pc

btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).

also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).

regards,
pc

Any update on the FreeBSD7 build?
I mapped libc_r.so and libpthread.so to libthr.so.2 in libmap.conf and I can start the avastd/avastlite without getting the LIBTHREAD_1_0 error.  However, both program will exit with "cannot allocate memory"

Here is the log from avastd.log

Code: [Select]

Feb 27 13:07:19 avastd[2836]: info: Starting avast! daemon
Feb 27 13:07:19 avastd[2836]: info: using this configuration for section 'local'
Feb 27 13:07:19 avastd[2836]: info:   daemons count: default=5, maximum=15
Feb 27 13:07:19 avastd[2836]: info:   avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Feb 27 13:07:19 avastd[2836]: info:   user: root
Feb 27 13:07:19 avastd[2836]: info:   datadir: /var/lib/avast4
Feb 27 13:07:19 avastd[2836]: info:   tempdir: /var/lib/avast/tmp
Feb 27 13:07:19 avastd[2836]: info:   licensefile: /var/lib/avast4/License.dat
Feb 27 13:07:19 avastd[2836]: info:   scan subdirectories: yes
Feb 27 13:07:19 avastd[2836]: info:   avast! engine flags: testall
Feb 27 13:07:19 avastd[2836]: info:   packers: types=A, maxdepth=32, summary archives=no
Feb 27 13:07:19 avastd[2836]: info:   packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Feb 27 13:07:19 avastd[2836]: info:                  maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Feb 27 13:07:19 avastd[2836]: info:   log scan results: logclean loginfected logscanerrors
Feb 27 13:07:19 avastd[2836]: info: listenning on unix socket /var/run/avast4/local.sock
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2837)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2838)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2839)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2840)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2841)
Feb 27 13:07:23 avastd[2836]: notice: process exited (pid=2840)
Feb 27 13:08:05 avastd[2836]: error: closing process local[2841]: cannot initialize avast! engine: Cannot allocate memory
Feb 27 13:08:05 avastd[2836]: notice: process exited (pid=2837)

Thanks

[zilog]

Hello,

Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.

Code: [Select]

lrwxr-xr-x  1 root  wheel   8 Jun 20  2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x  1 root  wheel   9 Jun 20  2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  10 Jun 20  2008 /usr/lib/libpthread_p.a -> libthr_p.a

I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.

The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found

error.

If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.

I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.

I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it

Thanks,

Daniel

Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically . Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 .

regards,
pc

btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).

also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).

regards,
pc

Any update on the FreeBSD7 build?
I mapped libc_r.so and libpthread.so to libthr.so.2 in libmap.conf and I can start the avastd/avastlite without getting the LIBTHREAD_1_0 error.  However, both program will exit with "cannot allocate memory"

Here is the log from avastd.log

Code: [Select]

Feb 27 13:07:19 avastd[2836]: info: Starting avast! daemon
Feb 27 13:07:19 avastd[2836]: info: using this configuration for section 'local'
Feb 27 13:07:19 avastd[2836]: info:   daemons count: default=5, maximum=15
Feb 27 13:07:19 avastd[2836]: info:   avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Feb 27 13:07:19 avastd[2836]: info:   user: root
Feb 27 13:07:19 avastd[2836]: info:   datadir: /var/lib/avast4
Feb 27 13:07:19 avastd[2836]: info:   tempdir: /var/lib/avast/tmp
Feb 27 13:07:19 avastd[2836]: info:   licensefile: /var/lib/avast4/License.dat
Feb 27 13:07:19 avastd[2836]: info:   scan subdirectories: yes
Feb 27 13:07:19 avastd[2836]: info:   avast! engine flags: testall
Feb 27 13:07:19 avastd[2836]: info:   packers: types=A, maxdepth=32, summary archives=no
Feb 27 13:07:19 avastd[2836]: info:   packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Feb 27 13:07:19 avastd[2836]: info:                  maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Feb 27 13:07:19 avastd[2836]: info:   log scan results: logclean loginfected logscanerrors
Feb 27 13:07:19 avastd[2836]: info: listenning on unix socket /var/run/avast4/local.sock
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2837)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2838)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2839)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2840)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2841)
Feb 27 13:07:23 avastd[2836]: notice: process exited (pid=2840)
Feb 27 13:08:05 avastd[2836]: error: closing process local[2841]: cannot initialize avast! engine: Cannot allocate memory
Feb 27 13:08:05 avastd[2836]: notice: process exited (pid=2837)

Thanks

Yes, i'm working on big FreeBSD cleanup, right now (and the whole previous week).

<whining>
Results are quite pesimistic, nearly all dirty hacks in our build tools are here because of ... FreeBSD oddities, and MUST stay here. It's really hard to produce binary app that work on all recent BSDs. We must offer at least 3 different "flavours" of them - libc_r, pthread and libthr ones. Plus, here's the infamous 64k stack-problem, silent threading lockup for libc_r/libc mixing (which occurs even when the library depends on libc_r), repeatedly changed meaning of -pthread linking scenarios, and even horrible tools like libtool that make usage of all workaround 10x more complex and then to "correct" linking back to the bad state.
</whining>

The (slightly reduced) set of resulting workaround works fine, as it seems for now, and so just expect the testing packages, probably tommorow (unless some other nightmare appears).

regards,
pc

PS: for validating, i'm using 12 different distros... uff. big mess, that FreeBSD .

[williamXP]

Hello,

Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.

Code: [Select]

lrwxr-xr-x  1 root  wheel   8 Jun 20  2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x  1 root  wheel   9 Jun 20  2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  10 Jun 20  2008 /usr/lib/libpthread_p.a -> libthr_p.a

I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.

The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found

error.

If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a

Code: [Select]

/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.

I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.

I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it

Thanks,

Daniel

Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically . Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 .

regards,
pc

btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).

also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).

regards,
pc

Any update on the FreeBSD7 build?
I mapped libc_r.so and libpthread.so to libthr.so.2 in libmap.conf and I can start the avastd/avastlite without getting the LIBTHREAD_1_0 error.  However, both program will exit with "cannot allocate memory"

Here is the log from avastd.log

Code: [Select]

Feb 27 13:07:19 avastd[2836]: info: Starting avast! daemon
Feb 27 13:07:19 avastd[2836]: info: using this configuration for section 'local'
Feb 27 13:07:19 avastd[2836]: info:   daemons count: default=5, maximum=15
Feb 27 13:07:19 avastd[2836]: info:   avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Feb 27 13:07:19 avastd[2836]: info:   user: root
Feb 27 13:07:19 avastd[2836]: info:   datadir: /var/lib/avast4
Feb 27 13:07:19 avastd[2836]: info:   tempdir: /var/lib/avast/tmp
Feb 27 13:07:19 avastd[2836]: info:   licensefile: /var/lib/avast4/License.dat
Feb 27 13:07:19 avastd[2836]: info:   scan subdirectories: yes
Feb 27 13:07:19 avastd[2836]: info:   avast! engine flags: testall
Feb 27 13:07:19 avastd[2836]: info:   packers: types=A, maxdepth=32, summary archives=no
Feb 27 13:07:19 avastd[2836]: info:   packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Feb 27 13:07:19 avastd[2836]: info:                  maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Feb 27 13:07:19 avastd[2836]: info:   log scan results: logclean loginfected logscanerrors
Feb 27 13:07:19 avastd[2836]: info: listenning on unix socket /var/run/avast4/local.sock
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2837)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2838)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2839)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2840)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2841)
Feb 27 13:07:23 avastd[2836]: notice: process exited (pid=2840)
Feb 27 13:08:05 avastd[2836]: error: closing process local[2841]: cannot initialize avast! engine: Cannot allocate memory
Feb 27 13:08:05 avastd[2836]: notice: process exited (pid=2837)

Thanks

Yes, i'm working on big FreeBSD cleanup, right now (and the whole previous week).

<whining>
Results are quite pesimistic, nearly all dirty hacks in our build tools are here because of ... FreeBSD oddities, and MUST stay here. It's really hard to produce binary app that work on all recent BSDs. We must offer at least 3 different "flavours" of them - libc_r, pthread and libthr ones. Plus, here's the infamous 64k stack-problem, silent threading lockup for libc_r/libc mixing (which occurs even when the library depends on libc_r), repeatedly changed meaning of -pthread linking scenarios, and even horrible tools like libtool that make usage of all workaround 10x more complex and then to "correct" linking back to the bad state.
</whining>

The (slightly reduced) set of resulting workaround works fine, as it seems for now, and so just expect the testing packages, probably tommorow (unless some other nightmare appears).

regards,
pc

PS: for validating, i'm using 12 different distros... uff. big mess, that FreeBSD .

Hi, nice to hear that FreeBSD7 build is coming.  I was actually installing a FreeBSD 5.5-R VM when I saw this post ...       Frankly, I would suggest that you should start to move to FreeBSD 6.x and 7.x now as 4.x and 5.x are end of life product.  Although I believe lots of people are still using 4.x/5.x, they will move to new version eventually.  Perhaps you could release new version/function on 6.x/7.x builds, and only maintain security/bug fix for 4.x/5.x.  Just my 2 cents.. 

[zilog]

Hallo,
it's rather about library-hell dependencies and workarounds - so, we'll support all of them, because many people changed the libraries to get other 3rd party apps running, so there's a mess in general.

some testing packages would be available tommorow.

regards,
pc

[zilog]

Hallo,
it's rather about library-hell dependencies and workarounds - so, we'll support all of them, because many people changed the libraries to get other 3rd party apps running, so there's a mess in general.

some testing packages would be available tommorow.

regards,
pc

Hallo, just to keep you informed,
bad news - one day more necessary (on that $#@!-bsd, gdb is unable to fire hardware watchpoints, and thus, it was necessary to trace manually through all those functions to the problematic place - uff.

good news - culprit found, finally - stdcall caller arg-coalescing breaks in this case the switch to auxiliary stack (because there are 64kB only stacks per thread, in general). In debug-build, of course, this optimisation is off and thus everything works :>

   466d7:       83 7e 1c 00             cmpl   $0x0,0x1c(%esi)
   466db:       75 1c                   jne    466f9 <avscanRepairEx+0xf191>
   466dd:       c7 45 e8 0c 00 00 00    movl   $0xc,0xffffffe8(%ebp)
   466e4:       ff 75 e8                pushl  0xffffffe8(%ebp)
   466e7:       68 bc cb 16 00          push   $0x16cbbc
   466ec:       e8 fc ff ff ff          call   466ed <avscanRepairEx+0xf185>
   466f1:       8b 45 e8                mov    0xffffffe8(%ebp),%eax
   466f4:       e9 5b ff ff ff          jmp    46654 <avscanRepairEx+0xf0ec>
   466f9:       6a 00                   push   $0x0
   466fb:       8d 45 f0                lea    0xfffffff0(%ebp),%eax
   466fe:       6a 00                   push   $0x0
   46700:       6a 00                   push   $0x0
   46702:       68 00 00 10 00          push   $0x100000
   46707:       50                      push   %eax
   46708:       6a 04                   push   $0x4
   4670a:       6a 00                   push   $0x0
   4670c:       e8 d5 08 0f 00          call   136fe6 <fsGetAvastOemString+0xaa3a>
   46711:       8b 45 f0                mov    0xfffffff0(%ebp),%eax
   46714:       05 00 ff 0f 00          add    $0xfff00,%eax
   46719:       89 65 ec                mov    %esp,0xffffffec(%ebp)
   4671c:       89 c4                   mov    %eax,%esp
   4671e:       ff 75 18                pushl  0x18(%ebp)
   46721:       ff 75 14                pushl  0x14(%ebp)
   46724:       ff 76 1c                pushl  0x1c(%esi)
   46727:       e8 ba bc ff ff          call   423e6 <avscanRepairEx+0xae7e>
   4672c:       88 c3                   mov    %al,%bl
   4672e:       8b 65 ec                mov    0xffffffec(%ebp),%esp
   46731:       83 c4 28                add    $0x28,%esp                                                        ;root of all evil
   46734:       ff 75 f0                pushl  0xfffffff0(%ebp)
   46737:       e8 46 17 0f 00          call   137e82 <fsGetAvastOemString+0xb8d6>
   4673c:       84 db                   test   %bl,%bl
   4673e:       59                      pop    %ecx
   4673f:       75 09                   jne    4674a <avscanRepairEx+0xf1e2>
   46741:       c7 45 e8 10 a4 00 00    movl   $0xa410,0xffffffe8(%ebp)
   46748:       eb 9a                   jmp    466e4 <avscanRepairEx+0xf17c>


.
pc

[zilog]

Hallo,
uff, never more . but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:

http://public.avast.com/~cimbal/freebsdalpha

NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000   sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.

NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).

regards,
pc

Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near

i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).

[williamXP]

Hallo,
uff, never more . but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:

http://public.avast.com/~cimbal/freebsdalpha

NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000   sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.

NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).

regards,
pc

Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near

i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).

Hi,

Thank you for your effort.  The program seems runs fine......  Just one glitch in the installtion.... The installation script will change the permission of /tmp to 0700, which cause many other programs panic, and also have some difficulties setting up the cron job.   Please see the error message for cron job below.

Code: [Select]

Installer will insert call for virus database update to the crontab now.
This task can be done by avastvpsupdate.sh or avastvpsupdate.pl.
Installer will check which way is suitable for you, and also will try
to download the latest database version. This step might take up to few
minutes under some circumstances, but can be interrupted anytime by
pressing Ctrl-C (in this case, add the line to the crontab manually
and probably fix the problem in /etc/avastvpsupdate.conf).
chmod: 3-03-09-15-32-23-77557: No such file or directory
crontab: no crontab for root