Anyterm Forum

aruzsi wrote:

Can you tell me what is the difference between anyterm-1.1.15 and anyterm-trunk recent version?
1.1.15 was able to compile and trunk not.

Not much difference, except for the changes that I have made for this idea.

The reason for the problem is that libpbe is a utility library that I also use in other projects (e.g. Decimail), and it has changed to add things that are not needed by Anyterm.  This should not be a problem, except that I unintentionally made a change in libpbe/FileDescriptor.hh that is not compatible with gcc-3.3.  A few hours ago I made some more changes that should have made it compatible again, but you say that it didn't work for you.  I would like to understand why because it does now compile for me with my version of gcc-3.3.

Sorry for the long delay. I had a big trouble with my Net.

phil wrote:

grep __GLIBCPP__ /usr/include/c++/3.3/i486-linux/bits/c++config.h
grep __GLIBCXX__ /usr/include/c++/3.3/i486-linux/bits/c++config.h

Or a file file with a similar name.  Somewhere you should find a definition containing a date, something like this:

#define __GLIBCPP__ 20050304

rattila@wsnote:/usr/include/c++/3.3.5/i586-suse-linux/bits> grep __GLIBCPP__ c++config.h
#define __GLIBCPP__ 20050117
grep __GLIBCXX__ /usr/include/c++/3.3/i486-linux/bits/c++config.h
is empty.

Ruzsi

phil wrote:

I have updated libpbe/src/FileDescriptor.hh so that it will try to work with your version of libstdc++.

No success:
rattila@wsnote:~/source/anyterm-trunk/apachemod> make
cd ../libpbe; \
make DISABLE_POSTGRESQL=1 DISABLE_IMAGEMAGICK=1 DISABLE_RECODE=1
make[1]: Entering directory `/home/rattila/source/anyterm-trunk/libpbe'
cd src; make ../libpbe.a
make[2]: Entering directory `/home/rattila/source/anyterm-trunk/libpbe/src'
g++ -D_REENTRANT -MM -MT HttpDaemon.d -MT HttpDaemon.o  -o HttpDaemon.d HttpDaemon.cc
HttpDaemon.cc:51:2: #error "Sorry, there is a problem with your compiler / C++ library.  Please ask for assistance"
make[2]: *** [HttpDaemon.d] Error 1
make[2]: Leaving directory `/home/rattila/source/anyterm-trunk/libpbe/src'
make[1]: *** [libpbe.a] Error 2
make[1]: Leaving directory `/home/rattila/source/anyterm-trunk/libpbe'
make: *** [../libpbe/libpbe.a] Error 2

Ruzsi

phil wrote:

svn status libpbe/src/FileDescriptor.hh

Nothing!

What do I do badly? File is exists. After svn update version was: 2053. I could see.
And an other file was modified, too in libpbe/src by svn.

Do I have to back again all svn anyterm-trunk?

Ruzsi

phil wrote:

My mistake.  Update and try again.

OK. My machine is compiling ... on version 2054. Just some minutes ...

Ruzsi

I went more further:
...
a - SmtpClient.o
a - utils.o
make[2]: Leaving directory `/home/rattila/source/anyterm-trunk/libpbe/src'
make[1]: Leaving directory `/home/rattila/source/anyterm-trunk/libpbe'
apxs2 -c -o anyterm.la Activity.lo anyterm.lo apache.lo auto_CgiParams.lo backend.lo diff.lo editscript.lo Globals.lo html.lo Session.lo SessionId.lo SharedObject.lo SubProcess.lo Terminal.lo UrlEncodedCgiParams.lo wapterm.lo -L/usr/local/lib -lrote -lstdc++ -lboost_thread -L../libpbe -lpbe
/usr/share/apache2/build/libtool --silent --mode=link gcc -o anyterm.la  -rpath /usr/lib/apache2 -module -avoid-version    Activity.lo anyterm.lo apache.lo auto_CgiParams.lo backend.lo diff.lo editscript.lo Globals.lo html.lo Session.lo SessionId.lo SharedObject.lo SubProcess.lo Terminal.lo UrlEncodedCgiParams.lo wapterm.lo -L/usr/local/lib -lrote -lstdc++ -lboost_thread -L../libpbe -lpbe
/usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: cannot find -lboost_thread
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536
.
make: *** [compile] Error 1

Of course boost rpm is installed.

Ruzsi

phil wrote:

I have just made a change to the libpbe Makefile which tries to work around it by skipping the things that need it.  Update and try again.

Instead of it I installed recode-devel. Recode was installed, but devel not.

Ruzsi

In libpbe/include/FileDescriptor.hh, line 470, change the date from 20060309 to 20050901.  Then tell me if it compiles.

The problem is that I don't know when a change happened in libstdc++: I know that the change was somewhere between 20050503 and 20060309, but I don't know the exact date.  Your version is in that space.

SebaMinguez wrote:

YES!

OK, I'll make that change in the next version.

/usr/lib/gcc/i586-suse-linux/4.0.2/../../../../i586-suse-linux/bin/ld: cannot find -lboost_thread-mt

Different distributions can't agree on what filenames to give the Boost libraries, and you may get something different if you build Boost from source.  I suggest that you edit apachemod/Makefile and change the definition of LINK_FLAGS to say -lboost_thread-gcc40-mt.

Phil.

> I document the instalation (in spanish) in my blog:

Bueno, puedo practicar mi espanol - entiendo bastante por mis vacaciones...

(Nota que este forum no accepta las caracteres non-ASCII!)

> *** The apxs program was not found.
> locate apxs2
> /usr/sbin/apxs2

At this point, you could just temporarily add /usr/sbin to your PATH and there would be no need to edit the Makefile.  Also works for apr_config.

I don't know why they put apxs in sbin; seems the wrong choice to me.

> ln -s /usr/local/include/boost_1_34_1/boost /usr/include/boost

Or, in apachemod/Makefile, add -I/usr/local/include to CPP_FLAGS.  On many systems, /usr/local/include is included in the gcc include path by default.  I'm not sure why Suse doesn't do this.

I hope the next steps work OK.

Phil.

Well, again,

YaST is not doin ANYTHING!!!!

This backs up to old behaviour including /etc/rc.config till SuSE 5.3 Since SuSE 6.0 YaST ist not modifing anything!

Also SuSE and now opensuse is one of the most standard compliant distributions. Run the LSB testsuit and check against the FHS ()which is part of LSB) if you don't belive.

(phil, I did'nt meant you)

greetings,
anniyka

http://www.pathname.com/fhs/pub/fhs-2.3 … DSYSTEMBI:

/sbin : System binaries
Purpose

Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. [18] Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin. [19]

[19]   

Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.

For example, files such as chfn which users only occasionally use must still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and must live in /bin for that reason.

We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users.

No simple user will ever use it, we can discuss if a module-developer is a normal user.

But the tool itself is defined:

man apxs2:

NAME 
       apxs - APache eXtenSion tool

So, no normal user will ever need to extend apache.

greetings,
anniyka