[PD] linking gem library on w32 mingw [was:Re: [Gridflow-dev] [gemdead]]

Patrice Colet colet.patrice at free.fr
Sat May 7 16:52:12 CEST 2011


 I tried to compile a pix_preview dll, it's almost there after some little hacks in source code:

pix_preview.cc:
#ifdef _WIN32
#define _WIN32_WINNT 0x0501
#include <ws2tcpip.h>
#include <windows.h>
#else
#include <netinet/in.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netdb.h>
#endif

pix_preview.h:
#ifndef _WIN32
#include <netinet/in.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netdb.h>
#endif


 but now something for the linking is missing,
it looks like it's the same error we get when compiling gridflow_gem library:

undefined reference to:
 « vtable for GemPixObj »
 « imageStruct::~imageStruct() »
 « GemBase::~GemBase() »
 
let me guess, gem have to be compiled first, anyone has done this on mingw?

----- "Antonio Roberts" <antonio at hellocatfood.com> a écrit :

> I've just come across [pix-preview], which is part of the pdvjtools
> package
> http://hangar.org/wikis/lab/lib/exe/detail.php?id=start%3Apuredata_pdvjtools&media=start:pix_preview_help_patch.png
> 
> Looks like it does similar to [gem_see] object that was just
> created...
> 
> On 30 April 2011 20:06, Antonio Roberts <antonio at hellocatfood.com>
> wrote:
> > This is amazing, thanks to you both!
> >
> > Ant
> >
> > On 30 April 2011 18:05, Jack <jack at rybn.org> wrote:
> >> Something like this could help.
> >> ++
> >>
> >> Jack
> >>
> >>
> >>
> >> Le samedi 30 avril 2011 à 12:06 +0100, ALAN BROOKER a écrit :
> >>> Hey Ant,
> >>>
> >>> This can definitely be done- I was working on/off on a sort of '
> #see
> >>> for gem' but haven't perfected it yet.
> >>>
> >>> The method is to render 3d objects into a buffer > to pix object
> >
> >>> then to #from_pix. Mathieu may know of a more efficient way of
> doing
> >>> this tho
> >>>
> >>> The attached patch (if it doesn't work when first opened, close
> then
> >>> re-open and should work) is what I was working on. As mentioned
> it's a
> >>> work in progress and I could probably do with some efficiency
> tips
> >>> here too!
> >>>
> >>> All the best
> >>>
> >>> Al
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Apr 30, 2011 at 10:19 AM, Antonio Roberts
> >>> <antonio at hellocatfood.com> wrote:
> >>> > Thanks and sorry that I didn't stick around to get the reply on
> IRC.
> >>> >
> >>> > Secondly, can the cube be rendered to an [#out window] object? I
> know
> >>> > [#from_pix] can handle [pix_] objects, and I've tried using a
> [cube]
> >>> > as a [pix_texture] that I can then send to [#from_pix] but no
> luck so
> >>> > far
> >>> >
> >>> > Ant
> >>> >
> >>> > On 30 April 2011 01:04, Mathieu Bouchard <matju at artengine.ca>
> wrote:
> >>> >>
> >>> >> from irc #dataflow :
> >>> >>
> >>> >> <hellocatfood> Is it possible to use [gemdead] with objects
> such as [cube]
> >>> >> and [sphere] in gridflow?
> >>> >>
> >>> >> In theory, I said no, but actually, [gemdead] doesn't prevent
> you from using
> >>> >> OpenGL elements, and things like [cube] and [sphere] don't
> check at all
> >>> >> whether they're given a real [gemhead] context, and don't seem
> to be doing
> >>> >> much that is related to it, therefore :
> >>> >>
> >>> >>  [gemhead]
> >>> >>   |
> >>> >>  [b]
> >>> >>   |
> >>> >>  [gemdead]
> >>> >>   |
> >>> >>  [cube]
> >>> >>
> >>> >> will really draw the cube as if you had done :
> >>> >>
> >>> >>  [gemhead]
> >>> >>   |
> >>> >>  [cube]
> >>> >>
> >>> >> I suspect that very few Gem object classes really depend on an
> authentic
> >>> >> GemState (one that was really created by [gemwin]). When you do
> find
> >>> >> exceptions, please tell me.
> >>> >>
> >>> >> But you may have to use [gemhead] anyway (as in the above
> example) as long
> >>> >> as [gemwin] decides when to clear the buffer and when to copy
> the buffer to
> >>> >> the screen, just because [gemwin] uses [gemdead] to say when
> it's the time
> >>> >> to draw.
> >>> >>
> >>> >>
>  _______________________________________________________________________
> >>> >> | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray,
> Montréal, QC
> >>> >>
> >>> >
> >>> > _______________________________________________
> >>> > Pd-list at iem.at mailing list
> >>> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >>> >
> >>> _______________________________________________
> >>> Gridflow-dev mailing list
> >>> Gridflow-dev at lists.artengine.ca
> >>> http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev
> >>
> >>
> >
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list

-- 
Patrice Colet 



More information about the Pd-list mailing list