[physfs] Getting every instance of overlapping files
Haydn Harach
hharach at gmail.com
Wed Aug 27 10:10:58 EDT 2014
I tried using "-static -lphysfs -dynamic" instead of "-lphysfs", but now it
breaks everything else (namely, SDL).
Here's a link to the files I've modified: physfs.h, physfs.c, libphysfs.a,
libphysfs.dll, and libphysfs.dll.a:
https://www.dropbox.com/s/4jjxhxodoxvlbr9/physfs%20modifications.zip?dl=0
On Wed, Aug 27, 2014 at 8:01 AM, Tim Čas <darkuranium at gmail.com> wrote:
> Yes, linking with that will link with the DLL. Try adding '-static' before
> '-lphysfs' and '-dynamic' after to link with the static lib.
>
> Can you upload the DLL and/or the sources somewhere so that I can take a
> look with 'nm' and try compiling myself?
> On Aug 27, 2014 3:51 PM, "Haydn Harach" <hharach at gmail.com> wrote:
>
>> I'm just linking with -lphysfs, like you said. I don't have MSYS. The
>> only source file I modified was physfs.c, I didn't add any.
>>
>>
>> On Wed, Aug 27, 2014 at 7:45 AM, Tim Čas <darkuranium at gmail.com> wrote:
>>
>>> How are you using libphysfs.a? I've often found that linking with just
>>> -lphysfs tends to make MinGW link with the DLL instead of the library.
>>>
>>> If you have MSYS, you can also try this to find out if the DLL exports
>>> the symbol (which would indicate that the problem is elsewhere):
>>> $ nm libphysfs.dll | grep openRead
>>>
>>> Oh and, I just had a thought --- when you added PHYSFS_openReadMulti,
>>> did you create any new source files? If you did, you have to run cmake
>>> again for it to recognize the new files? It is entirely possible that
>>> it's not compiling in said new file (though that wouldn't quite
>>> explain why the symbol exists in the static library).
>>>
>>> On 27 August 2014 15:21, Haydn Harach <hharach at gmail.com> wrote:
>>> > It creates "libphysfs.a", "libphysfs.dll", and "libphysfs.dll.a"
>>> >
>>> > I've tried using both the .dll and the non-.dll version of the .a
>>> library,
>>> > they both have the issues. Interestingly, when using libphysfs.a, it
>>> still
>>> > requires libphysfs.dll, even before I started modifying the source
>>> code.
>>> >
>>> >
>>> > On Wed, Aug 27, 2014 at 7:17 AM, Tim Čas <darkuranium at gmail.com>
>>> wrote:
>>> >>
>>> >> And did you also compile the DLLs, or did you only compile the static
>>> >> (*.a) library? MinGW tends to create one file for static builds (foo.a
>>> >> or libfoo.a) and two files for dynamic builds ({lib,}foo.dll.a and
>>> >> {lib,}foo.dll) --- it seems that you've perhaps only created the
>>> >> static library?
>>> >>
>>> >> On 27 August 2014 13:05, Haydn Harach <hharach at gmail.com> wrote:
>>> >> > Yes, I did replace the dll's. From what I gather,
>>> >> > `PHYSFS_openReadMulti` is
>>> >> > present in `physfs.a` but not in `physfs.dll`, and
>>> `PHYSFS_closeList` is
>>> >> > not
>>> >> > present in `physfs.a` (and presumably not in `physfs.dll`, either).
>>> >> >
>>> >> > I'm compiling both physfs and my app using MinGW-W64.
>>> >> >
>>> >> >
>>> >> > On Wed, Aug 27, 2014 at 3:39 AM, Tim Čas <darkuranium at gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> Did you replace the DLLs after compiling? The application might
>>> still
>>> >> >> be
>>> >> >> using the old one if you forgot to do that.
>>> >> >>
>>> >> >>
>>> >> >> On 27 August 2014 10:10, Haydn Harach <hharach at gmail.com> wrote:
>>> >> >>>
>>> >> >>> PHYSFS_openReadMulti compiles just fine, but then my app crashes
>>> >> >>> because
>>> >> >>> it can't find it in physfs.dll. So, it found it in the .a, but
>>> not in
>>> >> >>> the
>>> >> >>> .dll? what am I doing wrong compiling physfs? >.<
>>> >> >>>
>>> >> >>>
>>> >> >>> On Tue, Aug 26, 2014 at 9:51 AM, Haydn Harach <hharach at gmail.com>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Now I'm having trouble rebuilding the project. I'm trying to
>>> use a
>>> >> >>>> code::blocks project which I generated with cmake, changing only
>>> the
>>> >> >>>> 2 files
>>> >> >>>> (physfs.c and physfs.h). It compiles and builds just fine, but
>>> I'm
>>> >> >>>> getting
>>> >> >>>> "undefined reference to PHYSFS_closeList" now. What did I do
>>> wrong?
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Mon, Aug 25, 2014 at 6:55 PM, Haydn Harach <hharach at gmail.com
>>> >
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> Alrighty, here are the additions I've made to my physfs.c:
>>> >> >>>>>
>>> >> >>>>> PHYSFS_File **PHYSFS_openReadMulti(const char *_fname)
>>> >> >>>>> {
>>> >> >>>>> char *fname;
>>> >> >>>>> size_t len;
>>> >> >>>>>
>>> >> >>>>> BAIL_IF_MACRO(_fname == NULL, ERR_INVALID_ARGUMENT, 0);
>>> >> >>>>> len = strlen(_fname) + 1;
>>> >> >>>>> fname = (char *) __PHYSFS_smallAlloc(len);
>>> >> >>>>> BAIL_IF_MACRO(fname == NULL, ERR_OUT_OF_MEMORY, 0);
>>> >> >>>>>
>>> >> >>>>> FileHandle** ret = NULL;
>>> >> >>>>> unsigned int retcount = 0;
>>> >> >>>>>
>>> >> >>>>> if (sanitizePlatformIndependentPath(_fname, fname))
>>> >> >>>>> {
>>> >> >>>>> int fileExists = 0;
>>> >> >>>>> DirHandle *i = NULL;
>>> >> >>>>> fvoid *opaque = NULL;
>>> >> >>>>>
>>> >> >>>>> __PHYSFS_platformGrabMutex(stateLock);
>>> >> >>>>>
>>> >> >>>>> GOTO_IF_MACRO(!searchPath, ERR_NO_SUCH_PATH,
>>> openReadEnd);
>>> >> >>>>>
>>> >> >>>>> /* !!! FIXME: Why aren't we using a for loop here? */
>>> >> >>>>> i = searchPath;
>>> >> >>>>>
>>> >> >>>>> do
>>> >> >>>>> {
>>> >> >>>>> char *arcfname = fname;
>>> >> >>>>> if (verifyPath(i, &arcfname, 0))
>>> >> >>>>> {
>>> >> >>>>> opaque = i->funcs->openRead(i->opaque, arcfname,
>>> >> >>>>> &fileExists);
>>> >> >>>>> if (opaque)
>>> >> >>>>> {
>>> >> >>>>> // We found a valid file, let's prepare it.
>>> >> >>>>> FileHandle* h =
>>> >> >>>>> (FileHandle*)allocator.Malloc(sizeof(FileHandle));
>>> >> >>>>> if (h == NULL)
>>> >> >>>>> {
>>> >> >>>>> i->funcs->fileClose(opaque);
>>> >> >>>>> GOTO_MACRO(ERR_OUT_OF_MEMORY,
>>> openReadEnd);
>>> >> >>>>> }
>>> >> >>>>> memset(h, 0, sizeof(FileHandle));
>>> >> >>>>> h->opaque = opaque;
>>> >> >>>>> h->forReading = 1;
>>> >> >>>>> h->dirHandle = i;
>>> >> >>>>> h->funcs = i->funcs;
>>> >> >>>>> h->next = openReadList;
>>> >> >>>>> openReadList = h;
>>> >> >>>>>
>>> >> >>>>> // Add the file to the list
>>> >> >>>>> FileHandle** temp =
>>> >> >>>>> (FileHandle**)allocator.Malloc(sizeof(FileHandle) * (retcount +
>>> 1));
>>> >> >>>>> if (temp == NULL)
>>> >> >>>>> {
>>> >> >>>>> allocator.Free(h);
>>> >> >>>>> i->funcs->fileClose(opaque);
>>> >> >>>>> GOTO_MACRO(ERR_OUT_OF_MEMORY,
>>> openReadEnd);
>>> >> >>>>> }
>>> >> >>>>> if (ret != NULL)
>>> >> >>>>> {
>>> >> >>>>> memcpy(temp, ret, sizeof(FileHandle) *
>>> >> >>>>> retcount);
>>> >> >>>>> allocator.Free(ret);
>>> >> >>>>> }
>>> >> >>>>> temp[retcount] = h;
>>> >> >>>>> ++retcount;
>>> >> >>>>> ret = temp;
>>> >> >>>>> }
>>> >> >>>>> } /* if */
>>> >> >>>>> i = i->next;
>>> >> >>>>> } while ((i != NULL) && (!fileExists));
>>> >> >>>>>
>>> >> >>>>> // Add a null terminator to the list
>>> >> >>>>> if (ret != NULL)
>>> >> >>>>> {
>>> >> >>>>> FileHandle** temp =
>>> >> >>>>> (FileHandle**)allocator.Malloc(sizeof(FileHandle) * (retcount +
>>> 1));
>>> >> >>>>> if (temp == NULL)
>>> >> >>>>> GOTO_MACRO(ERR_OUT_OF_MEMORY, openReadEnd);
>>> >> >>>>>
>>> >> >>>>> memcpy(temp, ret, sizeof(FileHandle) * retcount);
>>> >> >>>>> allocator.Free(ret);
>>> >> >>>>>
>>> >> >>>>> temp[retcount] = NULL;
>>> >> >>>>> ret = temp;
>>> >> >>>>> }
>>> >> >>>>>
>>> >> >>>>> openReadEnd:
>>> >> >>>>> __PHYSFS_platformReleaseMutex(stateLock);
>>> >> >>>>> } /* if */
>>> >> >>>>>
>>> >> >>>>> __PHYSFS_smallFree(fname);
>>> >> >>>>> return ret;
>>> >> >>>>> } /* PHYSFS_openReadMulti */
>>> >> >>>>>
>>> >> >>>>> int PHYSFS_closeList(PHYSFS_file** list)
>>> >> >>>>> {
>>> >> >>>>> int retval = 1;
>>> >> >>>>>
>>> >> >>>>> for (PHYSFS_file** i = list; *i != NULL; ++i)
>>> >> >>>>> {
>>> >> >>>>> if (PHYSFS_close(*i) == 0)
>>> >> >>>>> retval = 0;
>>> >> >>>>> }
>>> >> >>>>>
>>> >> >>>>> allocator.Free(list);
>>> >> >>>>> return retval;
>>> >> >>>>> }
>>> >> >>>>>
>>> >> >>>>> Is there anything not immediately obvious that I'm missing?
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> On Mon, Aug 25, 2014 at 6:11 PM, Edward Rudd
>>> <urkle at outoforder.cc>
>>> >> >>>>> wrote:
>>> >> >>>>>>
>>> >> >>>>>> On Aug 25, 2014, at 8:06 PM, Haydn Harach <hharach at gmail.com>
>>> >> >>>>>> wrote:
>>> >> >>>>>>
>>> >> >>>>>> > Looking at PHYSFS_openRead() in physfs.c, I've found this
>>> little
>>> >> >>>>>> > snippet:
>>> >> >>>>>> >
>>> >> >>>>>> > do
>>> >> >>>>>> > {
>>> >> >>>>>> > char *arcfname = fname;
>>> >> >>>>>> > if (verifyPath(i, &arcfname, 0))
>>> >> >>>>>> > {
>>> >> >>>>>> > opaque = i->funcs->openRead(i->opaque,
>>> arcfname,
>>> >> >>>>>> > &fileExists);
>>> >> >>>>>> > if (opaque)
>>> >> >>>>>> > break;
>>> >> >>>>>> > } /* if */
>>> >> >>>>>> > i = i->next;
>>> >> >>>>>> > } while ((i != NULL) && (!fileExists));
>>> >> >>>>>> >
>>> >> >>>>>> > Now, from what I can see, this loop goes through all the
>>> paths,
>>> >> >>>>>> > and
>>> >> >>>>>> > the first one that satisfies the function and returns some
>>> data
>>> >> >>>>>> > (from the
>>> >> >>>>>> > openRead function) and causes 'opaque' to not be NULL, and
>>> thus
>>> >> >>>>>> > breaks out
>>> >> >>>>>> > of the loop.
>>> >> >>>>>> >
>>> >> >>>>>> > So, if I replaced "if (opaque) break;" with "if (opaque)
>>> >> >>>>>> > someVector.emplace_back(opaque, i);", then did some cleanup
>>> to
>>> >> >>>>>> > ensure that I
>>> >> >>>>>> > have a vector of FileHandle's instead of one, and return
>>> that,
>>> >> >>>>>> > this should
>>> >> >>>>>> > be exactly what I'm looking for, yes?
>>> >> >>>>>>
>>> >> >>>>>> More or less, yes that would be exactly what you were looking
>>> for.
>>> >> >>>>>> _______________________________________________
>>> >> >>>>>> physfs mailing list
>>> >> >>>>>> physfs at icculus.org
>>> >> >>>>>> http://icculus.org/mailman/listinfo/physfs
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>
>>> >> >>>
>>> >> >>>
>>> >> >>> _______________________________________________
>>> >> >>> physfs mailing list
>>> >> >>> physfs at icculus.org
>>> >> >>> http://icculus.org/mailman/listinfo/physfs
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> physfs mailing list
>>> >> >> physfs at icculus.org
>>> >> >> http://icculus.org/mailman/listinfo/physfs
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > physfs mailing list
>>> >> > physfs at icculus.org
>>> >> > http://icculus.org/mailman/listinfo/physfs
>>> >> >
>>> >> _______________________________________________
>>> >> physfs mailing list
>>> >> physfs at icculus.org
>>> >> http://icculus.org/mailman/listinfo/physfs
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > physfs mailing list
>>> > physfs at icculus.org
>>> > http://icculus.org/mailman/listinfo/physfs
>>> >
>>> _______________________________________________
>>> physfs mailing list
>>> physfs at icculus.org
>>> http://icculus.org/mailman/listinfo/physfs
>>>
>>
>>
>> _______________________________________________
>> physfs mailing list
>> physfs at icculus.org
>> http://icculus.org/mailman/listinfo/physfs
>>
>>
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20140827/7e39b7e6/attachment-0001.html>
More information about the physfs
mailing list