Automount for 0.3.x

[critor]

[tom]

[tom]

[tom]

[Lightning]

[critor]

I've had some free time, so I've taken a new look at this thread's problem.

Remember: we are trying to make an autofs/automount package for FreeSco.

With the same binaries and kernel, we've got something that works under ZipSlack, but not on FreeSco.


I've retried with FreeSco's last release (0.3.4) and autofs-3.1.3 and the problem remains the same:
automount aborts with the message "automount[4032]: cannot open lookup module file (Not an ELF file)".

I've taken a look at automount's sources.

The error happens when automount tries to load library lookup_file.so:
* dlopen(fnbuf, RTLD_NOW);

On FreeSco, I've putten that file in /pkg/usr/lib/autofs, and there is the symlink /usr/lib/autofs (so same location as on ZipSlack)

I've added some debug messages, and fnbuf contains the string "/usr/lib/autofs//lookup_file.so".

I don't know why there are 2 "/" after autofs, but the path is ok...
dlopen still fails... and dlerror returns the error string "not an ELF file".
So the problem is not compilation...


Even if I move, rename or delete lookup_file.so, dlerror still returns "not an ELF file" (instead of "file not found" or something like that...)



Don't you think there is something strange here?
Do you have any ideas on what the problem could be, or what other tests I could to in order to investigate the problem?


Thanks.


Download autofs-3.1.3 sources here: <a href='ftp://ftp.kernel.org/pub/linux/daemons/autofs/v3/autofs-3.1.3.tar.gz' target='_blank'>ftp://ftp.kernel.org/pub/linux/daemons/au...fs-3.1.3.tar.gz</a>

[Lightning]

[critor]

[Lightning]

[critor]

[critor]

I'm back.


I've made the test, and automount fails, wether there is a single or double-slash ("/") in the path.


I've made a little test-program in C. It just tries to open a .so file with the dlopen function.



Here is the source.

sotest:
#include <stdio.h>
#include dlfcn.h>

void main(int argc, char** argv)
{ printf("%s = %i\n", argv[1], dlopen( argv[1], RTLD_NOW));
}


gcc needs the parameter "-ldl".
dlopen returns 0 if anything is wrong.


With ZipSlack, the program succesfully loads mount_afs.so for example (that file comes with autofs).


With FreeSco, whatever path I give to the program (absolute, relative, with or without symbolic links, existing file or not...) it fails and the following message is displayed:

sotest: '/usr/lib/' is not an ELF file
sotest: '/lib/' is not an ELF file
<the path I gave>=0


Of course a directory is not an ELF file...
The problem seems to become a little more technical...


Any idea of what's happening?

[critor]

some more things to help you think about the problem:
Please, I really need your help...


I've looked at the man page for dlopen.

When given a not absolute path (not beginning with /), dlopen will look for the file in the following places:
* LD_LIBRARY_PATH (seems to not be set)
* /etc/ld.so.cache
* /usr/lib
* /lib

So now I understand (a little) why I've got an error (previous post) with /usr/lib and /lib directories.


Now, the problem is that dlopen (with FreeSco) does not seem to behave at all as the man page describes...
It is looking in /usr/lib and /lib although I've given an absolute path!!!

Note, that it does not say "/usr/lib/mount_afs.so is not an ELF file", but "/usr/lib is not an ELF file".

Could it be that dlopen's parameter is forgotten/erased/modified while the function is running?...

If parameter value is changes to "", this would mean a relative (not absolute) path, and produce a messages "/usr/lib/ is not an ELF file". And with automount, it would log the error in /var/messages (as described in earlier posts) "is not an ELF file".


This looks like a C-side-effect-bug (modifying a char* string), but once again everything works well with ZipSlack and the same binaries!!!


Can anybody help me understand? - Thanks.

[critor]

it seems I have to make questions and answers on my own...


I just managed to make automount binary work correctly!
guess what I've done...

I've just installed the bash package, package which comes with a new libc.so.5 (if I've well understood)


Will I now have answers about "why", now that the problem is allmost solved?

[Peppe/Sweden]

[critor]