Networked Media Tank

Full Version: cross toolchain and stat function
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
Most likely the stat structures are indeed defined differently (4 bytes as you seemed to have shown?) but I would expected larger differences, like size is 64bit in one side, and 32bit in another, but that is in the middle.
lundman Wrote:Reason llink do not run on pch natively is the stat() function returns huge values on size. So we need to solve this one..

What is the proper configure line or make line to compile for the NMT

when I type make I get this error in unrar-...seek

Code:
unicode.cpp: In function 'bool WideToChar(const wchar*, char*, int)':
unicode.cpp:19: error: 'wcstombs' was not declared in this scope
unicode.cpp: In function 'bool CharToWide(const char*, wchar*, int)':
unicode.cpp:69: error: 'mbstowcs' was not declared in this scope

Martin
It is a #define problem, it defines MBFUNCTIONS for everything except EMX, so just dont define it IIRC. Or something..
Thanks if you want to see if my toolchain is any different here it llink via the toolchain

http://ca.geocities.com/emveepee@rogers.com/llink.zip

I don't use it so I don't know what to look for.

Martin
lundman Wrote:Most likely the stat structures are indeed defined differently (4 bytes as you seemed to have shown?) but I would expected larger differences, like size is 64bit in one side, and 32bit in another, but that is in the middle.
Do you guys don't have the same issue with "busybox ls"??
I have the stat-offset issue when using lundman's inststuctions. If adding libc.a to $CTARGET/lib folder it works.

Using the "test" program, with added hexdump info of "struct stat", in this thread:
Code:
Test of stat function
!!! 00000000  01 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00
!!! 00000010  03 00 00 00 bd 13 00 00  ff 81 00 00 01 00 00 00
!!! 00000020  e9 03 00 00 e9 03 00 00  00 00 00 00 00 00 00 00
!!! 00000030  07 00 00 00 00 80 aa 2a  95 1b 00 00 00 00 00 00
!!! 00000040  a0 3f d0 47 00 05 40 00  f3 b1 d3 47 00 00 00 00
!!! 00000050  f3 b1 d3 47 ...
stMode = 10000 [000013BD]
../fun/test is not a regular file
../fun/test is not a directory

Using the "test" program with libc.a linked in:
Code:
Test of stat function
!!! 00000000  01 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00
!!! 00000010  bd 13 00 00 ff 81 00 00  01 00 00 00 e9 03 00 00
!!! 00000020  e9 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00
!!! 00000030  00 00 00 00 95 1b 00 00  00 00 00 00 a0 3f d0 47
!!! 00000040  00 00 00 00 f3 b1 d3 47  00 00 00 00 f3 b1 d3 47
!!! 00000050  ...
stMode = 100000 [000081FF]
../fun/test is a regular file
../fun/test is not a directory
Notice the bytes "03 00 00 00" at struct position 10h.

/next
That would be st_ino, defined either as:

Code:
#if (_MIPS_SIM == _MIPS_SIM_ABI32) || (_MIPS_SIM == _MIPS_SIM_NABI32)
struct stat {
        unsigned        st_dev;
        long            st_pad1[3];             /* Reserved for network id */
        ino_t           st_ino;

or
struct stat64 {
        unsigned long long      st_ino;

#if _MIPS_SIM == _MIPS_SIM_ABI64
struct stat {
        unsigned long           st_ino;

Is the good way with 32bit inode, or 64bit? Also, "ino_t" definition may vary.
Result of the test compiled with different toolchains :
Code:
#ls -alt test.cygwin test.groll test.lundman test.emveepee
-rwxrwxrwx    1 root     root         5817 Mar  9 15:10 test.cygwin
-rwxrwxrwx    1 root     root         5797 Mar  9 14:21 test.lundman
-rwxrwxrwx    1 root     root         5797 Mar  8 14:12 test.groll
-rwxrwxrwx    1 root     root         5798 Mar  6 18:51 test.emveepee
/opt/sybhttpd/localhost.drives/HARD_DISK#./test.cygwin
Test of stat function
stMode = 40000
./test is not a regular file
./test is a directory
/opt/sybhttpd/localhost.drives/HARD_DISK#./test.lundman
Test of stat function
stMode = 40000
./test is not a regular file
./test is a directory
/opt/sybhttpd/localhost.drives/HARD_DISK#./test.groll
Test of stat function
stMode = 40000
./test is not a regular file
./test is a directory
/opt/sybhttpd/localhost.drives/HARD_DISK#./test.emveepee
Test of stat function
stMode = 100000
./test is a regular file
./test is not a directory
emveepee wins ! Tongue
The question is : "Emveepee, what did you do different to make it work ?!?"
I can't say I trust mine either that's why I upload the pch version of llink for someone who knows it to test.

I can't remember if my toolchain has C99 math or not anymore I will check later, but I do know to get g++ to compile I had to remove this rm

# Remove the temporary headers, and compile it properly.
rm -rf /usr/local/$ARCH/$CTARGET/sys-include

Martin
lundman Wrote:That would be st_ino, defined either as:
Is the good way with 32bit inode, or 64bit? Also, "ino_t" definition may vary.
Lundman, if it's the extra 4 bytes in my post then I don't think it is as "bd 13 00 00" is the st_ino in this case and not "03 00 00 00 bd 13 00 00" which it should be if it's a long long or 64 bytes.

But in my installation, based on your cross-compile instructions, the st_pad1 is an array of 3 in asm/stat.h (ie original asm-mips) but array of 2 in bits/stats.h (which is the "_SYS_STAT_H" used by the test compile).
As "st_pad1" is starting on offset 08h, and "ino_t" at offset 10h (which is the same offset as "st_pad1[3]"), this also confirm the missmatching struct definitions. The correct offset for "ino_t" should be 14h.

Modified test program...
Code:
!!! __UCLIBC_HAS_LFS__
!!! _SYS_STAT_H
!!! _MIPS_SIM=00000001
!!! my_stat (out): filename=../fun/test, mode=000013BD, blks=00001000, blksize=00000000
!!! len: int=4, unsigned=4, long=4, ino_t=4, mode_t=4
!!! stat: 7ffcad38, st_dev=0000, st_pad1[0]=0008, st_pad1[2]=0010, st_ino=0010, st_mode=0014, st_blocks=0058, st_blksize=0054
!!! 00000000  01 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00
!!! 00000010  03 00 00 00 bd 13 00 00  ff 81 00 00 01 00 00 00
!!! 00000020  e9 03 00 00 e9 03 00 00  00 00 00 00 00 00 00 00

/next
next Wrote:But in my installation, based on your cross-compile instructions, the st_pad1 is an array of 3 in asm/stat.h (ie original asm-mips) but array of 2 in bits/stats.h (which is the "_SYS_STAT_H" used by the test compile).
Ahhhhhhh........ now I got both test program and busybox to work...

Revoced uClibc change #13027 ("previous st_dev change from unsigned long (4bytes) to __dev_t (8bytes) needed to shrink the pads as well to maintain ABI compat") http://www.uclibc.org/cgi-bin/viewcvs.cg...f_format=h

Now with st_pad1 array increased to 3 again, recompiling everything, then both this test program and busybox 1.9.1 works correctly.

Let me know if this change only works in my environment or if it is a "global" problem...

/next

PS! Thanks for letting me know I was not the only one with the "stat" problem, started to get crazy about this issue...
next Wrote:[
PS! Thanks for letting me know I was not the only one with the "stat" problem, started to get crazy about this issue...
I also thought that I was the only one when I started this thread... :wink:
I'll try your patch tomorrow.
Ah great, we have the answer, as to why it is a problem, when we are supposedly running the exact same versions is strange Smile

Maybe make a clean patch, and include it in the cross-compile instructions.
yay =)
groll Wrote:-rwxrwxrwx 1 root root 5797 Mar 8 14:12 test.groll
-rwxrwxrwx 1 root root 5798 Mar 6 18:51 test.emveepee
It explains also why emveepee's binary is 1 byte bigger.
A question remains : how emveepee did correct this bug even not knowing about it ? :lol:
groll Wrote:[quote="groll"]
A question remains : how emveepee did correct this bug even not knowing about it ? :lol:
Well it only proves that testing is the root of errors... not looking and not knowing they exist is same as they do not exist... :shock: :lol:

/next
Pages: 1 2 3 4
Reference URL's