prefix.cpp introduced a pthreads dependency that is breaking us on Win32...
Any suggestions on how to proceed?
I do think we ought to be able to use it in a threadsafe configuration, but it should be using the Glib threading wrappers for portability.
-mental
Make sure submit a bug report to autopackage so they're aware of it. They don't seem to have a bug tracker so I guess report it to autopackage-dev@...336...
Is there a way that the dependency can be eliminated? If not, is the routine necessary to be run on Win32? Since the purpose of prefix.cpp was to make autopackage viable, and since autopackage is a *nixish thing, maybe the pthreads dependent code could be autoconfed out?
Bryce
On Sun, 2 May 2004, MenTaLguY wrote:
prefix.cpp introduced a pthreads dependency that is breaking us on Win32...
Any suggestions on how to proceed?
I do think we ought to be able to use it in a threadsafe configuration, but it should be using the Glib threading wrappers for portability.
-mental
On Sun, 2004-05-02 at 22:19, Bryce Harrington wrote:
Make sure submit a bug report to autopackage so they're aware of it. They don't seem to have a bug tracker so I guess report it to autopackage-dev@...336...
Is there a way that the dependency can be eliminated? If not, is the routine necessary to be run on Win32? Since the purpose of prefix.cpp was to make autopackage viable, and since autopackage is a *nixish thing, maybe the pthreads dependent code could be autoconfed out?
Looking at the binreloc documentation, it can be turned off via a macro.
However, it would be nice if it could be extended to work for Win32, actually. Win32 has GetModuleFilename(), but you still need to do the rest of the heavy lifting yourself.
Given that Win32 isn't a goal for autopackage, I'm not sure how much sense it makes to try to push changes for Win32 upstream. But I don't like the idea of re-implementing much of the same functionality for Win32 either .. :/
-mental
On Sun, 2 May 2004, MenTaLguY wrote:
On Sun, 2004-05-02 at 22:19, Bryce Harrington wrote:
Make sure submit a bug report to autopackage so they're aware of it. They don't seem to have a bug tracker so I guess report it to autopackage-dev@...336...
Is there a way that the dependency can be eliminated? If not, is the routine necessary to be run on Win32? Since the purpose of prefix.cpp was to make autopackage viable, and since autopackage is a *nixish thing, maybe the pthreads dependent code could be autoconfed out?
Looking at the binreloc documentation, it can be turned off via a macro.
However, it would be nice if it could be extended to work for Win32, actually. Win32 has GetModuleFilename(), but you still need to do the rest of the heavy lifting yourself.
Given that Win32 isn't a goal for autopackage, I'm not sure how much sense it makes to try to push changes for Win32 upstream. But I don't like the idea of re-implementing much of the same functionality for Win32 either .. :/
Well, one of the reasons the autopackage folks want to have it implemented in a real app is to uncover issues like this, that other potential autopackage users might also run up against. I bet it would be worth dropping them a note, even if we go ahead with the macro for now. Might be something they'll want to implement in the future.
Bryce
On Sun, 02 May 2004 23:46:15 -0700, Bryce Harrington wrote:
Looking at the binreloc documentation, it can be turned off via a macro.
Yeah, just autoconf it out or something. It's not a big deal, as AFAIK the codepaths which use binreloc in Inkscape do not need to be thread safe.
Well, one of the reasons the autopackage folks want to have it implemented in a real app is to uncover issues like this, that other potential autopackage users might also run up against. I bet it would be worth dropping them a note, even if we go ahead with the macro for now. Might be something they'll want to implement in the future.
Yes we know this is a problem. For projects using GTK/Glib we want to get a binreloc patch into glib. I know how to write the Win32 equivalent code so it should be portable at least to a variety of UNIXes, Linux and Win32 if not MacOS.
For now you can special case prefix.cpp to do whatever you want (if you modify the semantics of any of the functions though be sure to rename them). It's just a generic kit you can adapt to your needs. In future, there will hopefully be a g_get_binary_path() function.
thanks -mike
--- MenTaLguY <mental@...3...> wrote:
prefix.cpp introduced a pthreads dependency that is breaking us on Win32...
Any suggestions on how to proceed?
I fixed my build by dling the win32 pthreads from here http://sources.redhat.com/pthreads-win32/
dont know if the added dep is worth it for the windows build or not but it gets it building again :)
__________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
participants (4)
-
Bryce Harrington -
John Cliff -
MenTaLguY -
Mike Hearn