On Thu, 2007-08-23 at 12:28 +0200, Gianni Costanzi wrote:
> Hi,
> I'm working on an olsrd plugin that uses pthreads and I've spent last
> days dealing with some strange segmentation faults and other problems
> when running olsrd on my ARMEB APs.. All my problems were related to
> libpthread, which I did not specify in the Makefile when olsrd
> executable is linked..
> BTW, I've specified it but I've also made some modifications to
> Makefile, Makefile.inc and make/Makefile.linux, since there were the
> following "problems" in my opinion:
> 
> - -O2 and -g should not be specified together.. when you debug you do
> not usually want optimized code (I've specified -ggdb in the following
> diff output, you can replace with -g if you don't use gdb)

But then I would activate -O2 per default and comment out the -g option.
It
doesn't fell right to have per default a "primarily debugging
configuration".
If someone develops and/or debugs, he can fix the options.

> - -pthread should be specified to gcc along with -lpthread, since this
> last one links the libpthread library and -pthread does some other
> work:
> "GCC MAN PAGE--> -pthread   Add support for multithreading using the
> POSIX threads library.  This option sets flags for both the
> preprocessor and linker.  This option does not affect the thread
> safety of object code produced  by the compiler or that of libraries
> supplied with it."
ACK, adding "-pthread" very probably a good thing.

AFAICS the bmf, dyn_gw and tas plugin actually use threads.
- I don't know if and/or who uses TAS (does actually anyone use it?).
- dyn_gw is used on dedicated devices IIRC (since they plugins
  pings around to see if the uplink is available and is thus not
  normally usable). Or has this changed?
- Leaves bmf as the major user.
And the core (read: the olsrd as such) is ATM single-threaded (with the
obvious "problem" that e.g. lots of and/or - especially - slow clients
of
the httpinfo/txtinfo/... plugins can severely disturb the performance.
The current "solution" is: Then do not do it if it hurts.) - there is no
synchronization around (and thus no idea/concept/... on which is locked
and when. Deadlocks are the usual consequence if locking is done not
good enough).

Is the lack of synchronization is a problem or concern for the Bmf
plugin
(or the others)?

> - libraries should be specified before the source files.

Why this?
- It shouldn't really matter for shared libraries (*.so*)[0].
- Static libraries (*.a) - which are merely an aggregation of *.o files
-
  must be placed after the objects (and in the correct order if they are
  dependencies between libraries) because objects from the .a are only
pulled
  in from if there is an unresolved symbol at that point.
If you look at make's default rules (`make -p /dev/null`), you will see
that
LDLIBS is also at the end of the commandline (and LDFLAGS is at the
front).
So I clearly think this is wrong.

> - $(CFLAGS) is missing when compiling/linking olsrd

We have at that line no .c files there so that should not be needed.
Or did I miss something?

	Bernd

[0]: I think I read once that a shared lib is actually only mentioned in
     the result if it actually resolves a symbol. Which implies that you
     have to put it at the end since linkers (in the Unix world) are
pretty
     simple tools - they just walk through the command line from left to
right.
     But there were some other conditions (or was it on Solaris years
ago?) so
     ignore that more or less.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




