Cross compiling syslog-ng - problem with pthread_spin_lock
Hi, I am trying to cross compile syslog-ng for my embedded platform. When I run ./configure pointing it to the proper tool chain, it indicates "checking for pthread_spin_lock... no". And when I compile, it complains - "iv_thr.h:97: error: conflicting type qualifiers for 'pthread_spinlock_t'" Can someone please let me know how to go past this error? Am I missing a prerequisite library? -- Regards, Radha <http://www.sradhakrishna.com>
Radha Krishna Srimanthula <srimanthula.radhakrishna@gmail.com> writes:
Hi,
I am trying to cross compile syslog-ng for my embedded platform. When I run ./configure pointing it to the proper tool chain, it indicates "checking for pthread_spin_lock... no". And when I compile, it complains - "iv_thr.h:97: error: conflicting type qualifiers for 'pthread_spinlock_t'"
I suspect ivykis (lib/ivykis/) is a bit buggy when cross-compiling. Since it fails to detect pthread_spin_lock, it will have HAVE_PTHREAD_SPIN_LOCK disabled, which in turn means that it will try to typedef pthread_spinlock_t to an int. But! Your embedded platform DOES have pthread_spin_lock_t, so this will fail. I would suggest editing lib/ivykis/config.h after configure, and enabling HAVE_PTHREAD_SPIN_LOCK. Hopefully this'll help. (Why the detection fails, though, is not entirely clear to me..) -- |8]
On Fri, 2012-02-24 at 13:20 +0100, Gergely Nagy wrote:
Radha Krishna Srimanthula <srimanthula.radhakrishna@gmail.com> writes:
Hi,
I am trying to cross compile syslog-ng for my embedded platform. When I run ./configure pointing it to the proper tool chain, it indicates "checking for pthread_spin_lock... no". And when I compile, it complains - "iv_thr.h:97: error: conflicting type qualifiers for 'pthread_spinlock_t'"
I suspect ivykis (lib/ivykis/) is a bit buggy when cross-compiling. Since it fails to detect pthread_spin_lock, it will have HAVE_PTHREAD_SPIN_LOCK disabled, which in turn means that it will try to typedef pthread_spinlock_t to an int. But! Your embedded platform DOES have pthread_spin_lock_t, so this will fail.
I would suggest editing lib/ivykis/config.h after configure, and enabling HAVE_PTHREAD_SPIN_LOCK.
Hopefully this'll help.
(Why the detection fails, though, is not entirely clear to me..)
It'd make sense to forward this email to libivykis-discuss@lists.sourceforge.net so the ivykis authors become aware of the issue. -- Bazsi
Hello, I have a small problem with the newly compiled 3.4 version's init script in Debian like environments(Debian wheezy and Linux Mint Debian Edition). It loads syslog-ng upon startup in runlevel 2, but I cannot stop the program later by /etc/init.d/syslog-ng stop as it is shown twice in the process list with a low process ID first around 1500 and second time the running instance that I can control, but the low PID version loads back the closed instance. Is it a multithread issue maybe? I've just set syslog-ng to run on multiple cores. Or Is it possibly a misconfigure of my init script? If I list the running instances and kill them all then syslog-ng stops, but I guess this is not the best way to shutdown the service. Thanks for your replies Gabor
Jenei Gábor <jengab@elte.hu> writes:
I have a small problem with the newly compiled 3.4 version's init script in Debian like environments(Debian wheezy and Linux Mint Debian Edition). It loads syslog-ng upon startup in runlevel 2, but I cannot stop the program later by /etc/init.d/syslog-ng stop as it is shown twice in the process list with a low process ID first around 1500 and second time the running instance that I can control, but the low PID version loads back the closed instance.
The lower PID is the supervisor, you can disable it by passing --process-mode=background to syslog-ng (the default is safe-background, which launches the supervisor).
Is it a multithread issue maybe? I've just set syslog-ng to run on multiple cores. Or Is it possibly a misconfigure of my init script? If I list the running instances and kill them all then syslog-ng stops, but I guess this is not the best way to shutdown the service.
I suppose the problem is that your init script is not supervisor-aware. The init script I use in my own debianisation[1] does work with the supervisor, so it might be useful to have a look at it, and see if it works for you, or if you can modify yours based on that. [1]: https://raw.github.com/algernon/syslog-ng/debian/3.3/debian/syslog-ng-core.s... -- |8]
participants (4)
-
Balazs Scheidler
-
Gergely Nagy
-
Jenei Gábor
-
Radha Krishna Srimanthula