[PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM

Hans-Christoph Steiner hans at eds.org
Mon Aug 24 01:34:13 CEST 2009


Hey Matju,

 From my perspective, adding -lstdc++ has more problems than just  
making a simple libstdc++.pd_linux and loading that.  For example, the  
Debian package will then require libstdc++.  Plus it means another  
difference from Pd-vanilla.  Its not really something I know about,  
and therefore would not be a candidate for maintaining it.  Someone  
else would have to step up on that front.  The libstdc++.pd_linux  
could easily be included with Gridflow.  Or using the libdir format  
like Gem perhaps, where it loads a shared library first as part of the  
process of loading the lib.

Do you have any documentation on this as a suggested workaround?

.hc

On Aug 23, 2009, at 2:30 PM, Mathieu Bouchard wrote:

>
> Hi Hans,
>
> Could we please get Pd-extended to link the "pd" executable to  
> libstdc++.so ? Afaik, this is a fix for a possibly wide category of  
> problems but that is currently only "known" to affect GridFlow when  
> loading GEM while the driver named "fglrx" is in use (ATI video).
>
> AFAIK, this problem affects any lib that uses the "throw" keyword in  
> C++ code, whenever the ATI driver is loaded _before_ the standard  
> library of C++, in which case it will provide its own version of a  
> portion of the C++ standard library, which is incompatible (sort of  
> like the DLL Hell on Windows). This driver is typically loaded by  
> anything linked to OpenGL directly or indirectly (usually GEM, but  
> could also be 3DP, OpenSceneGraph, etc)
>
> So, what I'm asking, is to link Pd itself to a library that it  
> doesn't need, in order to force the bug out, so that this problem  
> doesn't have to be addressed anywhere else. I believe that it is far  
> easier to prevent this bug from the Pd executable than to make any  
> kind of elaborate circus with the loading-order of pdsettings and  
> pdrc and a little dummy .pd_linux (which has -lstdc++ without using  
> it, and has an empty _setup).
>
> If you want, you can think of it as the first step for putting  
> GridFlow in pd-extended.
>
> diff from Claude:
>
> ------------------8<--------cut-here--------8<------------------
> --- pd-0.41-4/src/makefile.in.orig      2008-03-15  
> 00:03:00.000000000 +0000
> +++ pd-0.41-4/src/makefile.in   2009-08-23 18:55:35.000000000 +0100
> -121,7 +121,7 @@
>        $(CC) $(CFLAGS)  $(STRIPFLAG) -o $(BIN_DIR)/pdreceive  
> u_pdreceive.c
>
> $(PDEXEC): $(OBJ) $(BIN_DIR)
> -       cd ../obj;  $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $ 
> (OBJ) $(LIB)
> +       cd ../obj;  $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $ 
> (OBJ) $(LIB) -lstdc++
>
> $(BIN_DIR)/pd-gui: $(GOBJ) $(GSRC)
>        cd ../obj; $(CC) $(INCLUDE) -o $(BIN_DIR)/$(GUINAME) $(GOBJ) $ 
> (GLIB)
> ------------------8<--------cut-here--------8<------------------
>
> _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801



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

Computer science is no more related to the computer than astronomy is  
related to the telescope.      -Edsger Dykstra






More information about the Pd-dev mailing list