Hi,
After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled from tarballs), suddenly it didn't find my "C:\Windows" any more. Worked before, same 'puter, config files, etc (TM). Tried with CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we ruled out the obvious (yes, the directory exists, here is my config file, no, I don't confuse root and non-root, ...), and got down to add traces and dug in the code.
So, for some reason, the readdir calls from files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL), but the directory entry name returned (dirent->d_name) is always the empty string (*(dirent->d_name)=='\0')!
So I checked if readdir worked generally on my system, it does, this program does the expected thing: int main(void) {//Tst code DIR *mydir; struct dirent *entr; mydir = opendir("/"); while ((entr = readdir(mydir))) { TRACE("Dir_entry: %s\n", entr->d_name); } closedir(mydir); }
I even went the extra mile and compiled it with exactly the same options (minus the various -I's) as dos_fc.c gets in wine, it works.
Then, I added that code snippet (without the "int main(void)", obviously) to wine's main(). Worked. So I went down the stack of called functions, putting that same snippet in each function to see when it breaks:
It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That function calls files/directory.c:DIR_Init(), and there, it doesn't work (ie name is always empty string) in DIR_Init(). After DIR_Init() returns, it still works in MAIN_MainInit().
I tried to find a difference between these files, but they get compiled with the same compile options, combined by "ld -r" along with other .o's in files/files.o, resp. loader/loader.o, and the two latter go in libntdll.so.
What could be the difference that makes readdir "break"?
I've put the test code snippet just before the call to DIR_Init in MAIN_MainInit, and just after variable declaration in DIR_Init, so it's not a function that DIR_Init calls that "breaks havoc".
Well... We're lost there. No idea. Anyone of you?
Anyway, here's some info on my system, just giving random info, I don't really know which one will be useful:
Pentium III 500 / 440BX motherboard SuSE 6.4 distrib "base" with several self-compiled "add-ons", "upgrades", and some newer SuSE RPM's installed (from 7.0, 7.1 or 7.2). Along the latter (newer RPM than SuSE 6.4), the glibc... glibc-2.2-9 Linux 2.2.20 (Was using .19 when problem started) Soundblaster AWE32 3Com NIC (3C905B) Adaptec SCSI controller (AHA-3950U2) gcc 2.95.2 GNU ld 2.9.5 binutils-2.9.5.0.24-30
Err... What more??? Any additional info useful? Just ask. (except r00t password, "of course" ;-> )
Thank you for your time,
On Sun, Nov 18, 2001 at 08:17:24PM +0100, Lionel Elie Mamane wrote:
Hi,
After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled from tarballs), suddenly it didn't find my "C:\Windows" any more. Worked before, same 'puter, config files, etc (TM). Tried with CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we ruled out the obvious (yes, the directory exists, here is my config file, no, I don't confuse root and non-root, ...), and got down to add traces and dug in the code.
So, for some reason, the readdir calls from files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL), but the directory entry name returned (dirent->d_name) is always the empty string (*(dirent->d_name)=='\0')!
Did you upgrade glibc?
Ciao, Marcus
On Sun, Nov 18, 2001 at 10:26:20PM +0100, Marcus Meissner wrote:
So, for some reason, the readdir calls from files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL), but the directory entry name returned (dirent->d_name) is always the empty string (*(dirent->d_name)=='\0')!
Did you upgrade glibc?
Well, yes, but not between the compilation and the running. Did a fresh recompile of 20010418 with the new glibc (I honestly don't remember if the 20010418 release was compiled with the "old" one or the "new"), works. 20011004 does not. With the same glibc.
Horrible doubt... Have I upgraded the _header_ files too? rpm would have loudly complained if I hadn't. It would have. Or am I too used to Debian quality? I didn't upgrade the headers. Doing so. Recompiling. OK, problem solved. Sorry.
Now, if someone could explain to me how the symptoms...
On Sun, 18 Nov 2001, Lionel Elie Mamane wrote:
It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That function calls files/directory.c:DIR_Init(), and there, it doesn't work (ie name is always empty string) in DIR_Init(). After DIR_Init() returns, it still works in MAIN_MainInit().
I tried to find a difference between these files, but they get compiled with the same compile options, combined by "ld -r" along with other .o's in files/files.o, resp. loader/loader.o, and the two latter go in libntdll.so.
What could be the difference that makes readdir "break"?
One file includes config.h before including system (libc) headers, the other does not. config.h may contain definitions that affect the structures that get included. For example, _FILE_OFFSET_BITS 64, which requests 64-bit filesystem stuff.