Cross-compile problem with path in 3.2.4
Hi! I cross compiled syslog-ng 3.2.4 for my ARM board. I called ./configure with the usual --host, --prefix and --exec-prefix options. Then I ran make with DESTDIR to my cross target directory. I moved everything to my ARM target and syslog-ng starts up. While it locates and loads the configuration files properly, there is a problem with the modules: ~ # syslog-ng Error opening plugin module; module='syslogformat', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='basicfuncs', error='//lib/syslog-ng/: cannot read file data: Is a directory' Plugin module not found in 'module-path'; module-path='/lib/syslog-ng', module='afsocket' Error opening plugin module; module='affile', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afprog', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afuser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='dbparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='csvparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='syslogformat', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='basicfuncs', error='//lib/syslog-ng/: cannot read file data: Is a directory' Plugin module not found in 'module-path'; module-path='/lib/syslog-ng', module='afsocket' Error opening plugin module; module='affile', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afprog', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afuser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='dbparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='csvparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='confgen', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='confgen', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error parsing source, source plugin system not found in /etc/syslog-ng/syslog-ng.conf at line 10, column 2: Checking the directory shows: /etc2/syslog-ng # ll /lib/syslog-ng/ drwxr-xr-x 2 root root 1024 Jun 14 16:01 ./ drwxr-xr-x 7 root root 3072 Jun 14 16:01 ../ -rw-r--r-- 1 root root 139122 Jun 14 16:01 libaffile.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libaffile.la* -rw-r--r-- 1 root root 110150 Jun 14 16:01 libafprog.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libafprog.la* -rw-r--r-- 1 root root 227144 Jun 14 16:01 libafsocket-notls.a -rwxr-xr-x 1 root root 1313 Jun 14 16:01 libafsocket-notls.la* -rw-r--r-- 1 root root 484708 Jun 14 16:01 libafsocket-tls.a -rwxr-xr-x 1 root root 1326 Jun 14 16:01 libafsocket-tls.la* lrwxrwxrwx 1 root root 18 Jun 14 16:03 libafsocket.so -> libafsocket-tls.so@ -rw-r--r-- 1 root root 89662 Jun 14 16:01 libafuser.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libafuser.la* -rw-r--r-- 1 root root 26398 Jun 14 16:01 libbasicfuncs.a -rwxr-xr-x 1 root root 1301 Jun 14 16:01 libbasicfuncs.la* -rw-r--r-- 1 root root 15366 Jun 14 16:01 libconfgen.a -rwxr-xr-x 1 root root 1292 Jun 14 16:01 libconfgen.la* -rw-r--r-- 1 root root 18030 Jun 14 16:01 libconvertfuncs.a -rwxr-xr-x 1 root root 1307 Jun 14 16:01 libconvertfuncs.la* -rw-r--r-- 1 root root 96416 Jun 14 16:01 libcsvparser.a -rwxr-xr-x 1 root root 1298 Jun 14 16:01 libcsvparser.la* -rw-r--r-- 1 root root 265984 Jun 14 16:01 libdbparser.a -rwxr-xr-x 1 root root 1314 Jun 14 16:01 libdbparser.la* -rw-r--r-- 1 root root 78426 Jun 14 16:01 libdummy.a -rwxr-xr-x 1 root root 1286 Jun 14 16:01 libdummy.la* -rw-r--r-- 1 root root 1662352 Jun 14 16:01 libsyslog-ng.a -rwxr-xr-x 1 root root 1265 Jun 14 16:01 libsyslog-ng.la* -rw-r--r-- 1 root root 60868 Jun 14 16:01 libsyslogformat.a -rwxr-xr-x 1 root root 1307 Jun 14 16:01 libsyslogformat.la* I tried calling syslog-ng --module-path=/lib/syslog-ng too, but I get the same result, Any idea to get around that would be appreciated :) Best Regards and thanks in advance Ulrich
Ulrich Prinz <uprinz2@netscape.net> writes:
I cross compiled syslog-ng 3.2.4 for my ARM board. I called ./configure with the usual --host, --prefix and --exec-prefix options. Then I ran make with DESTDIR to my cross target directory. I moved everything to my ARM target and syslog-ng starts up. While it locates and loads the configuration files properly, there is a problem with the modules:
[..snip..]
Checking the directory shows: /etc2/syslog-ng # ll /lib/syslog-ng/ drwxr-xr-x 2 root root 1024 Jun 14 16:01 ./ drwxr-xr-x 7 root root 3072 Jun 14 16:01 ../ -rw-r--r-- 1 root root 139122 Jun 14 16:01 libaffile.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libaffile.la*
[..snip..] The reason it doesn't work, is because the shared objects are missing: it will not load .a files, only .sos. (More or less...) Could you perhaps send a complete build log, along with the output of configure? (Privately to me works aswell, as the full log might be too big for the list) I might be able to figure out why the shared libs did not get built. In the mean time, as a workaround, I'd suggest compiling syslog-ng in an emulator instead: that's a lot slower, but I know that it works, that's how I got syslog-ng onto my router ;) -- |8]
Hi! I sent you the logs, did you get them? If there is anything I can do else, just leave me a message. The results will be posted in here, so anyone else running into that can find the solution. Best Regards Ulrich -----Original Message----- From: Gergely Nagy <algernon@balabit.hu> To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Sent: Wed, Jun 15, 2011 9:54 am Subject: Re: [syslog-ng] Cross-compile problem with path in 3.2.4 Ulrich Prinz <uprinz2@netscape.net> writes:> I cross compiled syslog-ng 3.2.4 for my ARM board. I called ./configure > with the usual --host, --prefix and --exec-prefix options. Then I ran > make with DESTDIR to my cross target directory.> I moved everything to my ARM target and syslog-ng starts up. While it > locates and loads the configuration files properly, there is a problem > with the modules:[..snip..]> Checking the directory shows:> /etc2/syslog-ng # ll /lib/syslog-ng/> drwxr-xr-x 2 root root 1024 Jun 14 16:01 ./> drwxr-xr-x 7 root root 3072 Jun 14 16:01 ../> -rw-r--r-- 1 root root 139122 Jun 14 16:01 libaffile.a> -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libaffile.la*[..snip..]The reason it doesn't work, is because the shared objects are missing:it will not load .a files, only .sos. (More or less...)Could you perhaps send a complete build log, along with the output ofconfigure? (Privately to me works aswell, as the full log might be toobig for the list)I might be able to figure out why the shared libs did not get built.In the mean time, as a workaround, I'd suggest compiling syslog-ng in anemulator instead: that's a lot slower, but I know that it works, that'show I got syslog-ng onto my router ;)-- |8]______________________________________________________________________ ________Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ngDocumentation: http://www.balabit.com/support/documentation/?product=syslog-ngFAQ: http://www.balabit.com/wiki/syslog-ng-faq
Ulrich Prinz <uprinz2@netscape.net> writes:
Hi!
I sent you the logs, did you get them?
Got them, thanks. I'll report back (with the list copied, of course) as soon as I have something. (Might take a little while, as my time today is unfortunately rather limited :() -- |8]
On Wed, 2011-06-15 at 03:45 -0400, Ulrich Prinz wrote:
Hi!
I cross compiled syslog-ng 3.2.4 for my ARM board. I called ./configure with the usual --host, --prefix and --exec-prefix options. Then I ran make with DESTDIR to my cross target directory. I moved everything to my ARM target and syslog-ng starts up. While it locates and loads the configuration files properly, there is a problem with the modules:
~ # syslog-ng Error opening plugin module; module='syslogformat', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='basicfuncs', error='//lib/syslog-ng/: cannot read file data: Is a directory' Plugin module not found in 'module-path'; module-path='/lib/syslog-ng', module='afsocket' Error opening plugin module; module='affile', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afprog', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afuser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='dbparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='csvparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='syslogformat', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='basicfuncs', error='//lib/syslog-ng/: cannot read file data: Is a directory' Plugin module not found in 'module-path'; module-path='/lib/syslog-ng', module='afsocket' Error opening plugin module; module='affile', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afprog', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='afuser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='dbparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='csvparser', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='confgen', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error opening plugin module; module='confgen', error='//lib/syslog-ng/: cannot read file data: Is a directory' Error parsing source, source plugin system not found in /etc/syslog-ng/syslog-ng.conf at line 10, column 2:
Checking the directory shows: /etc2/syslog-ng # ll /lib/syslog-ng/ drwxr-xr-x 2 root root 1024 Jun 14 16:01 ./ drwxr-xr-x 7 root root 3072 Jun 14 16:01 ../ -rw-r--r-- 1 root root 139122 Jun 14 16:01 libaffile.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libaffile.la* -rw-r--r-- 1 root root 110150 Jun 14 16:01 libafprog.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libafprog.la* -rw-r--r-- 1 root root 227144 Jun 14 16:01 libafsocket-notls.a -rwxr-xr-x 1 root root 1313 Jun 14 16:01 libafsocket-notls.la* -rw-r--r-- 1 root root 484708 Jun 14 16:01 libafsocket-tls.a -rwxr-xr-x 1 root root 1326 Jun 14 16:01 libafsocket-tls.la* lrwxrwxrwx 1 root root 18 Jun 14 16:03 libafsocket.so -> libafsocket-tls.so@ -rw-r--r-- 1 root root 89662 Jun 14 16:01 libafuser.a -rwxr-xr-x 1 root root 1289 Jun 14 16:01 libafuser.la* -rw-r--r-- 1 root root 26398 Jun 14 16:01 libbasicfuncs.a -rwxr-xr-x 1 root root 1301 Jun 14 16:01 libbasicfuncs.la* -rw-r--r-- 1 root root 15366 Jun 14 16:01 libconfgen.a -rwxr-xr-x 1 root root 1292 Jun 14 16:01 libconfgen.la* -rw-r--r-- 1 root root 18030 Jun 14 16:01 libconvertfuncs.a -rwxr-xr-x 1 root root 1307 Jun 14 16:01 libconvertfuncs.la* -rw-r--r-- 1 root root 96416 Jun 14 16:01 libcsvparser.a -rwxr-xr-x 1 root root 1298 Jun 14 16:01 libcsvparser.la* -rw-r--r-- 1 root root 265984 Jun 14 16:01 libdbparser.a -rwxr-xr-x 1 root root 1314 Jun 14 16:01 libdbparser.la* -rw-r--r-- 1 root root 78426 Jun 14 16:01 libdummy.a -rwxr-xr-x 1 root root 1286 Jun 14 16:01 libdummy.la* -rw-r--r-- 1 root root 1662352 Jun 14 16:01 libsyslog-ng.a -rwxr-xr-x 1 root root 1265 Jun 14 16:01 libsyslog-ng.la* -rw-r--r-- 1 root root 60868 Jun 14 16:01 libsyslogformat.a -rwxr-xr-x 1 root root 1307 Jun 14 16:01 libsyslogformat.la*
I tried calling syslog-ng --module-path=/lib/syslog-ng too, but I get the same result,
Any idea to get around that would be appreciated :)
although I didn't get the build log, I might be able to help to diagnose the problem. You seem to have static libraries only, which is strange as the configure script contains LT_INIT([dlopen disable-static]) e.g. static libraries are disabled by default. They probably get reenabled, because libtool is unable to detect how to generate shared libraries. Then, the 2nd problem seems to be that the Glib call g_module_build_path() returns a bogus shared library name, which doesn't contain the basename of the module at all, instead it points to the plugin base directory. This is strange, but this is probably a glib compilation issue. In my ancient glib version, this function looks like: static gchar* _g_module_build_path (const gchar *directory, const gchar *module_name) { if (directory && *directory) { if (strncmp (module_name, "lib", 3) == 0) return g_strconcat (directory, "/", module_name, NULL); else return g_strconcat (directory, "/lib", module_name, "." G_MODULE_SUFFIX, NULL); } else if (strncmp (module_name, "lib", 3) == 0) return g_strdup (module_name); else return g_strconcat ("lib", module_name, "." G_MODULE_SUFFIX, NULL); } I don't see how this could possibly return that name that you are seeing. How did you set up your build environment? Did you compile glib, eventlog and others by hand? -- Bazsi
Balazs Scheidler <bazsi@balabit.hu> writes:
Any idea to get around that would be appreciated :)
although I didn't get the build log, I might be able to help to diagnose the problem.
I'll forward the build & config logs privately.
You seem to have static libraries only, which is strange as the configure script contains
LT_INIT([dlopen disable-static])
What I've found so far, is that during configure, the script correctly detects that the target architecture supports shared libraries, but when it tries to check whether libtool supports them, it concludes that it does not. This is what I saw in the config.log: configure:9376: checking whether the armel-unknown-linux-gnueabi-gcc-std=gnu99 linker (armel-unknown-linux-gnueabi-ld) supports shared libraries configure:10367: result: yes [...] configure:10606: checking dynamic linker characteristics configure:11269: result: no According to m4/libtool.m4, the result of "checking dynamic linker characteristics" is $dynamic_linker. Which gets set to "no" for some reason. I did not manage to get further than that yet, unfortunately. I wanted to prepare a patch that makes libtool.m4 a bit more verbose, so we could see what goes wrong and where, but didn't have the time yet. -- |8]
On Fri, 2011-06-24 at 14:34 +0200, Gergely Nagy wrote:
Balazs Scheidler <bazsi@balabit.hu> writes:
Any idea to get around that would be appreciated :)
although I didn't get the build log, I might be able to help to diagnose the problem.
I'll forward the build & config logs privately.
You seem to have static libraries only, which is strange as the configure script contains
LT_INIT([dlopen disable-static])
What I've found so far, is that during configure, the script correctly detects that the target architecture supports shared libraries, but when it tries to check whether libtool supports them, it concludes that it does not.
This is what I saw in the config.log:
configure:9376: checking whether the armel-unknown-linux-gnueabi-gcc-std=gnu99 linker (armel-unknown-linux-gnueabi-ld) supports shared libraries configure:10367: result: yes [...] configure:10606: checking dynamic linker characteristics configure:11269: result: no
According to m4/libtool.m4, the result of "checking dynamic linker characteristics" is $dynamic_linker. Which gets set to "no" for some reason.
I did not manage to get further than that yet, unfortunately. I wanted to prepare a patch that makes libtool.m4 a bit more verbose, so we could see what goes wrong and where, but didn't have the time yet.
As far as I see, the dynamic_linker is determined based on $host_os variable, which probably gets set based on the --host parameter. And it seems to be unknown. Hmm.. your configure option seems to include --host=i686 which is not a complete host identifier. This is probably the root cause, but honestly I'm not that much into cross compilation, so I can't help too much in this regard. -- Bazsi
participants (3)
-
Balazs Scheidler
-
Gergely Nagy
-
Ulrich Prinz