[PD-dev] open_via_path() weirdness

Hans-Christoph Steiner hans at at.or.at
Tue Apr 28 17:21:30 CEST 2009


On Apr 28, 2009, at 3:38 AM, IOhannes m zmoelnig wrote:

> 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... :-)

Yes, but _WIN32 is a good habit to get into.  This stuff is annoying,  
but if we use the same macro everywhere, it can save us lots of little  
annoyances down the line when things break because the differences in  
macros, platforms, and compilers.

>>>> 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 ;-)

Well, if you want to have a work session on this, I'd be glad (in a  
masochistic kind of way) to help you out with this.  We could have a  
session on #dataflow and invite some actual windows people :)  I think  
it would save us both a lot of work in the long run.  I'd bet you'd be  
able to make MinGW Gem builds in GNU/Linux! :)

.hc

> but of course you are right...
>
>
>
>
>
> mfga.sdr
> IOhannes
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev







----------------------------------------------------------------------------

"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White








More information about the Pd-dev mailing list