Zlib (libz.dylib) issue with plugin dylib

K

kuroyume

Registered
Now here's one that I can't figure out or find an answer. My plugin is compiling and linking into a PPC/i386 dylib. I'm using the -lz flag for the linker and include the zlib headers (zconf.h and zlib.h) as usual. No warnings or errors related to zlib. I am certain that libz.dylib (and its variations) exist in at least /usr/lib/ and in Developer/..../usr/lib/.

I 'install' the plugin dylib into the host application and run the application. The plugin works. I then attempt to call zlib functions and the first one, gzopen(), returns false. Now, realize that this plugin has been running for over a year on three systems: Windows, Window x64, and MacOS(9/10) and for hundreds of users! But, all versions have been using static library compiles of zlib (.lib) built into the plugin. So there is absolutely nothing wrong with my code - don't even go there. ;)

What jewel of information am I missing?

Thanks,
Robert
 
Well, it's been a long time - but then I put this problem aside to do *real* work instead of banging my ahead against a wall. :)

The problem turns out not to be related to zlib gzopen() directly, but a situation of MacOS X path descriptions generally (fopen() fails as well). Reading around, I see that the path FSRef should be passed through FSRefMakePath(). Problem here is that I'm working with path strings - usually absolute full paths. Seems that these are the worst to use (just great).

This is a C++ plugin for an application. There is no Carbon or Cocoa or Darwin built into the plugin SDK. When I get a Filename (SDK class - multi-platform), it is a path representation. How would one pass a path string through an FSRef (for instance) and back to a string for fopen() and gzopen() - that works? If Apple wants to abandon such support, then maybe they should provide a zlib interface that DOESN'T depend on gzopen() - if there is one, would be nice to hear about it (nothing from my extremely thorough research into this problem).

The '/Volumes/' workaround just creates a file at the root, like "HD/folder1/folder2/folder2/file.ext". That's not useful.

Totally understand Apple's desire to use the more sophisticated filesystem specs for OSX, but I find this abandonment of older apis to be shortsighted. People will be using fopen() for many decades to come (as it has been used for a couple decades previously) - its behaviour should be maintained. This is the only OS that does this (in my limited scope). Windows, Windows x64, MSDOS, AmigaOS, MacOS 9, Beos, Unixes all support these to some extent or another.

Thank you very much,

Robert
 
Back again. :)

I've long since found a way around this UB problem - "/Volumes/" fix works once you can get the volume name to append to this. Thankfully, the SDK now provides a way to do this (hmmm, wonder why?).

Now I have a more interesting problem. gzopen() and multibyte characters in filenames in UB. I have no problems using zlib (libz.dylib) in UB and no problems on Windows or PPC (CodeWarrior) versions when multibyte characters appear in filepath names. But gzopen() is failing if a multibyte character is included in a filepath name string using libz.dylib and XCode to compile Universal Binary. So far, I've tried all of the String to char* encodings available from the SDK being used - no go. The internet has been scoured for information - eyes crossed and still no go.

Is there some information on how to handle this?

Thanks for reading...
 
You must log in or register to reply here.
Back
Top