[PD-dev] open_via_path() weirdness

IOhannes m zmoelnig zmoelnig at iem.at
Tue Apr 28 09:38:51 CEST 2009

Hans-Christoph Steiner wrote:
> On Apr 27, 2009, at 6:28 PM, Martin Peach wrote:
>> IOhannes m zmoelnig wrote:
>>> hi all,
>>> in the course of trying to find the filehandle-leak bug in Gem i 
>>> found a weird problem with open_via_path().
>>> can anybody find anything wrong with the attached code?
>>> if not, try the attached patch as well.
>> A minor thing is that you use #ifdef __WIN32__ instead of #ifdef MSW, 
>> which may or may not work.
> _WIN32 is the preferred version of that macro:

ok; __WIN32__ is probably set as well (either by the compiler or 
manually by me), at least the __WIN32__ branch does get evaluated 
(putting "#error bla" in there will make the compiler choke).

i can hardly believe that this is the cause of my problems... :-)

>>> everything works fine on linux, but on w32 i cannot close the 
>>> file-handle anymore (i get an errno of EBADF, which means that fd 
>>> isn't a valid open file descriptor).
>>> which in turn results in a filehandle leak.
>> I don't know if it's related but I had trouble with the very similar 
>> canvas_open on WinXP in the [which] object. I compiled it with 
>> VisualStudioC++2005ExpressEdition against various pd.libs from 
>> Miller's site. Every time Pd would crash whenever i tried to use the 
>> fd, although the same code runs fine on linux (no need for a pd.lib 
>> there).

yes the dynamic linker in linux is a bit more relaxed.

the other observation is interesting:
i assume that miller is building with VC9 (aka Visual Studio 2008), at 
least after a short glance on the makefile.nt

i am building with Visual Studio 2003 (VC7.1), which might be the 
problem (sorry forgot to mention that in my original email).

i will try building Pd locally and see whether this changes anything.

>> So imagine my surprise when which works fine when built as part of 

...when which works... uff :-)

>> pd-extended on Hans' machine. So I think that I'm seeing some 
>> incompatibility of the dlls as made with MinGW and VC.

yes, but the weird thing is, that both Pd and my external are built with 
proprietary bullshit from microsoft. so shan't they be compatible?

> Yeah, I think its probably good to stick with MinGW throughout.

i still have not found time to build a fully functional Gem on w32 with 
MinGW. i am glad that i have a (carefully handcrafted) setup that allows 
me to "just" build Gem with M$VC. i am currently not planning to invest 
time before my harddisk breaks ;-)

but of course you are right...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090428/5a56d841/attachment.bin>

More information about the Pd-dev mailing list