Could not resolve function 'stat' in libc.so

I have the below error when launching TTsZipPackage 3.3.1 under Ubuntu 12.04 LTS Linux. If you click OK the app runs, but fails later when I go to unZip a file. I searched and found a ‘stat’ routine within the Zip libraries:
dim stat as unix_stat_struct_linux
declare function stat lib SystemLib (path as CString, dataOut as Ptr) as Integer
static stat as new MemoryBlock(512)

Anyone know of a workaround?

[code]Runtime Error
Press OK to Continue
Press Cancel to Quit.

Please report what caused this error
along with the information below.

Common/Loaders/Loader.cpp: 176
Failure Condition: functionEntry
Could not resolve function ‘stat’ in libc.so[/code]

Let’s ask help from the author: @Thomas Tempelmann , I know he knows very much about this subject and will find how to fix it. :wink:

David, is this Ubuntu 12.04, 32 or 64 bits?

I don’t know if this info can help Thomas, by I checked a Ubuntu 12.04 32 bits and found the following:

sudo su

# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.2 LTS
Release:	12.04
Codename:	precise
# uname -m
i686

# cd /usr/lib/i386-linux-gnu/
# file libc.so
libc.so: ASCII English text

# cat libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/i386-linux-gnu/libc.so.6 /usr/lib/i386-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib/i386-linux-gnu/ld-linux.so.2 ) )

# cd /lib/i386-linux-gnu/
# ls -l libc.so.6
lrwxrwxrwx 1 root root 12 Jan 28  2013 libc.so.6 -> libc-2.15.so

# ls -l libc-2.15.so
-rwxr-xr-x 1 root root 1730024 Jan 28  2013 libc-2.15.so

# objdump -tT libc-2.15.so|grep stat
00033830  w   DF .text	0000010b  GLIBC_2.0   setstate_r
000725f0 g    DF .text	00000026  GLIBC_2.0   _IO_file_stat
000ddbb0  w   DF .text	000000b3  GLIBC_2.1   statvfs64
000dd840 g    DF .text	00000092  GLIBC_2.4   __fxstatat64
000dd490 g    DF .text	000000b8  GLIBC_2.0   __lxstat
000dd930  w   DF .text	00000043  GLIBC_2.0   fstatfs
000336b0  w   DF .text	00000089  GLIBC_2.0   setstate
000dda40 g    DF .text	000000af  GLIBC_2.1   statvfs
000ddaf0 g    DF .text	000000b3  GLIBC_2.1   fstatvfs
000fc250 g    DF .text	00000041  GLIBC_2.0   pthread_attr_setdetachstate
00033620  w   DF .text	00000088  GLIBC_2.0   initstate
0007b420  w   DF .text	000001e2  GLIBC_2.0   malloc_stats
000749a0 g    DF .text	00000042  GLIBC_2.0   _IO_str_init_static
000dd5a0 g    DF .text	00000044  GLIBC_2.2   __fxstat64
000dd5a0 g    DF .text	00000044 (GLIBC_2.1)  __fxstat64
0007a0a0  w   DF .text	000001c0  GLIBC_2.0   malloc_get_state
0012abe0 g    DF .text	00000074  GLIBC_2.0   __frame_state_for
001a8a90 g    DO .bss	0000000c  GLIBC_2.0   svcauthdes_stats
00115c70 g    DF .text	00000023  GLIBC_2.0   xdr_keystatus
000ff8b0 g    DF .text	0000001c  GLIBC_2.2   __res_state
000dd5f0 g    DF .text	00000044 (GLIBC_2.1)  __lxstat64
000dd5f0 g    DF .text	00000044  GLIBC_2.2   __lxstat64
000dd9e0  w   DF .text	0000005b  GLIBC_2.1   fstatfs64
001a5224 g    DO .data	00000004  GLIBC_2.1   argp_err_exit_status
000dd8e0 g    DF .text	00000043  GLIBC_2.2   __statfs
000dd550 g    DF .text	00000044  GLIBC_2.2   __xstat64
000dd550 g    DF .text	00000044 (GLIBC_2.1)  __xstat64
000fc200 g    DF .text	00000041  GLIBC_2.0   pthread_attr_getdetachstate
000dd3d0 g    DF .text	000000b8  GLIBC_2.0   __fxstat
000ddc70  w   DF .text	000000b7  GLIBC_2.1   fstatvfs64
000ecc00 g    DF .text	0000006a  GLIBC_2.0   ustat
000dd8e0  w   DF .text	00000043  GLIBC_2.0   statfs
000fc990  w   DF .text	00000041  GLIBC_2.0   pthread_setcancelstate
000dd980  w   DF .text	0000005b  GLIBC_2.1   statfs64
000dd310 g    DF .text	000000b8  GLIBC_2.0   __xstat
000dd780 g    DF .text	000000b2  GLIBC_2.4   __fxstatat
00079910  w   DF .text	00000470  GLIBC_2.0   malloc_set_state
000faca0  w   DF .text	000000c2  GLIBC_2.1   argp_state_help
00033b00  w   DF .text	0000015e  GLIBC_2.0   initstate_r

(Thanks for including me in this discussion. I had seen the post with the topic, but made no connection to my Zip classes, so I didn’t look into the conversation.)

Okay, so I screwed this up. I wrote and tested the TTsFolderItem.Exists function on OSX but not on Linux. On Linux, something like __lxstat should be used, see TTsFolderItem.update.
Or, if you know you won’t work add symlinks, simply remove the entire Exists function, because then RB’s FolderItem.Exists will be used (which has a problem with symlinks, see <https://xojo.com/issue/27683>)

Can you fix this yourself for now? I’ll see that I release a fix soon. After I’ve tested it properly.

Alright. v3.2.2 fixes the issue and also hopefully solves finding the libz file on Linux by using not a full path any more but just the complete name: “libz.so.1”.

http://www.tempel.org/RB/ZipPackage

It works now — no longer gives the error on launching. When unzipping the below line has a problem, so I put it inside a try…end try command and it works OK. Not sure the effect on Norton.

zdest.CreationDate = d // !TT 21Jun05 added to prevent Norton and other tools from complaining about creation > modification date

Norton? Bruhahaaa. That shows how old this code is. Norton Utils for Mac was a tool to check the integrity of HFS volumes. It would report warnings if the file’s modification date was before its creation date.

Now sure why you’d get an exception there, though. When I tried 3.3.2 on Windows and Linux, I saw no such exception, so I can’t tell what you’re seeing there.

Can you tell me what kind of exception it was? Was it a NilObjectExc, i.e. was zdest nil? No, that makes no sense, because the code makes sure that zdest is not nil earlier on. Odd.

Would be nice if you could double check that for me so that I can fix my code accordingly.

Thomas

Oh, poop! It only happens in Xojo. I am still editing and testing in the old IDE because I find the new IDE still pretty unusable compared to the old one. Anyway.

And that’s just another example why the new IDE isn’t up to it yet: It does stop at an exception, shows me the line that you pointed out, and shows the little red “bug” icon. But it doesn’t tell me WHICH exception occured! Not even if I hover the mouse over it (in Xojo r1 this used to work still, at least). So I can’t even tell what the problem is. Sigh.

By adding a try/catch wrapper for “RuntimeException” I could figure out that it’s throwing an “UnsupportedOperationException”, with the message “Changing the creation date is not supported”. Good idea to have a function that used to set the ErrorCode property of the FolderItem for such errors before is now thowing an exception instead. Adds lots of surprises to old, well debugged code. Yay!

New version 3.3.3 is out.

On the slightly bright side, the newer version of the IDE will have an ‘Exception’ variable in the variables pane that you can look at like a normal variable.

Sneaky. But thanks!

Still, the IDE not showing anything as it used to still sucks. I’d think it would improve - how can it happen that it gets worse instead?

In fact, check this out: <https://xojo.com/issue/28916>

I am curious, but It must be a private kind of feedback that sub-xojo-pro licensees can’t read.

Oh, right. It refers to the upcoming beta version, because it’s gotten even worse there. We’ll see if RS can do something about it once it gets out…