[physfs] Getting every instance of overlapping files
Haydn Harach
hharach at gmail.com
Thu Aug 28 02:04:42 EDT 2014
I'm using physfs-2.0.3.
I'm putting the .dll in the same directory as the code::blocks
project, which is where it expects you to put .dll's. I tried putting
it into the "bin/debug" folder, which I assumed was incorrect, but lo
and behold it finds the function now. I guess if you have .dll's
there, it uses those instead of the ones stored with the project file.
So, PHYSFS_openReadMulti works* now, but it still can't find
PHYSFS_closeList at all (wont even compile).
And by works, I mean it technically compiles and doesn't crash. It
doesn't actually work, it still only finds a single instance of a file
that I distinctly put into multiple places for testing.
On Wed, Aug 27, 2014 at 8:40 AM, Haydn Harach <hharach at gmail.com> wrote:
> I'm using physfs-2.0.3.
>
> I'm putting the .dll in the same directory as the code::blocks project,
> which is where it expects you to put .dll's. I tried putting it into the
> "bin/debug" folder, which I assumed was incorrect, but lo and behold it
> finds the function now. I guess if you have .dll's there, it uses those
> instead of the ones stored with the project file.
>
> So, PHYSFS_openReadMulti works* now, but it still can't find
> PHYSFS_closeList at all (wont even compile).
>
> And by works, I mean it technically compiles and doesn't crash. It doesn't
> actually work, it still only finds a single instance of a file that I
> distinctly put into multiple places for testing.
>
> PHYSFS_file** files = PHYSFS_openReadMulti("module.data");
> int num = 0;
> for (PHYSFS_file** i = files; *i != NULL; ++i)
> {
> ++num;
> }
> cout << "Found " << num << " copies of 'module.data'\n";
>
> From this I get "Found 1 copies of 'module.data'", when I know that there
> should be 3.
>
>
> On Wed, Aug 27, 2014 at 8:29 AM, Tim Čas <darkuranium at gmail.com> wrote:
>>
>> Which version of PhysFS is that based on? (so that I can download the
>> other files)
>>
>> Also, you mentioned that it doesn't find the symbol in the DLL ---
>> where are you putting said DLL? Is it in the same directory as the
>> program? (it might be finding a different, older DLL)
>>
>> On 27 August 2014 16:10, Haydn Harach <hharach at gmail.com> wrote:
>> > 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
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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
>
>
More information about the physfs
mailing list