I believe this is true... the old NX-something-something is apparently obsolete and anyway wasn't working well. If there's something else I should be using I'd like to know...
cheers Miller
On Wed, Sep 20, 2006 at 10:44:03AM -0500, chris clepper wrote:
Is dlopen() now the only loading code on OSX as of 0.40?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 9/20/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
I believe this is true... the old NX-something-something is apparently obsolete and anyway wasn't working well. If there's something else I should be using I'd like to know...
That is probably the technically correct way to proceed from now on. I don't think dlopen() will load bundles properly which makes for the incompatibility with previously built externals some are experiencing.
On Sep 20, 2006, at 12:07 PM, chris clepper wrote:
On 9/20/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote: I believe this is true... the old NX-something-something is apparently obsolete and anyway wasn't working well. If there's something else I should be using I'd like to know...
That is probably the technically correct way to proceed from now
on. I don't think dlopen() will load bundles properly which makes
for the incompatibility with previously built externals some are
experiencing.
Yes, on Mac OS X, the externals have to be built against a Pd that
supports dlopen(), otherwise they won't work.
.hc
On 9/20/06, Hans-Christoph Steiner hans@eds.org wrote:
Yes, on Mac OS X, the externals have to be built against a Pd that supports dlopen(), otherwise they won't work.
I think they just need to be built as dylib and not bundle. I have not tested 0.40 to confirm yet.
On Sep 20, 2006, at 7:38 PM, chris clepper wrote:
On 9/20/06, Hans-Christoph Steiner hans@eds.org wrote:
Yes, on Mac OS X, the externals have to be built against a Pd that
supports dlopen(), otherwise they won't work.I think they just need to be built as dylib and not bundle. I have
not tested 0.40 to confirm yet.
...thought I mentioned this before, back when I first discovered that
apple had blessed dlopen() over NSBundle & friends? If not, then
yes, I am building externals as dynamic library's, which can be done by:
-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup
...in other words, "-bundle -undefined suppress -flat_namespace" is
deprecated, but oddly enough, I have no problems loading them with
the dlopen() loader code, even mixing up bundles and dylibs...
...lastly, for optimized builds, apple continues to recommend -Os
over -O2 or -O3...
...so, in sum, here's the linker line from a recent development build
of gem:
/usr/bin/g++-4.0 -o /Users/tigital/puredataDev/Gem/build/Development/ Gem.pd_darwin -L/Users/tigital/puredataDev/Gem/build/Development - L../../dev/libs -L../GemLibs/FTGL/mac/build/Deployment -F/Users/ tigital/puredataDev/Gem/build/Development -F/Users/tigital/Library/ Frameworks -filelist /Users/tigital/puredataDev/Gem/build/ GEM_darwin.build/Development/gem_darwin.build/Objects-normal/ppc/ Gem.LinkFileList -framework AGL -framework Carbon -framework GLUT - framework OpenGL -framework QuickTime -lftgl -arch ppc -Wl,- single_module -install_name @executable_path/../Resources/extra/ Gem.pd_darwin -Wl,-Y,1455 -dynamiclib -mmacosx-version-min=10.3 - undefined dynamic_lookup -lz -lfreetype -Xlinker -Y -Xlinker 100
jamie
james tittle wrote:
On Sep 20, 2006, at 7:38 PM, chris clepper wrote:
On 9/20/06, Hans-Christoph Steiner hans@eds.org wrote:
Yes, on Mac OS X, the externals have to be built against a Pd that supports dlopen(), otherwise they won't work.
I think they just need to be built as dylib and not bundle. I have not tested 0.40 to confirm yet.
...thought I mentioned this before, back when I first discovered that apple had blessed dlopen() over NSBundle & friends? If not, then yes, I am building externals as dynamic library's, which can be done by:
-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup
...in other words, "-bundle -undefined suppress -flat_namespace" is deprecated, but oddly enough, I have no problems loading them with the
wow! do the change the preferred way of linking with every minor release?
i can understand that there might be some changes in the preferred loading mechanism after the macintel change (with the goal of supporting both architectures). but afair, they only changed the fundamental architecture once in the last 10 years...
dlopen() loader code, even mixing up bundles and dylibs...
...lastly, for optimized builds, apple continues to recommend -Os over -O2 or -O3...
...so, in sum, here's the linker line from a recent development build of gem:
/usr/bin/g++-4.0 -o /Users/tigital/puredataDev/Gem/build/Development/Gem.pd_darwin -L/Users/tigital/puredataDev/Gem/build/Development -L../../dev/libs -L../GemLibs/FTGL/mac/build/Deployment -F/Users/tigital/puredataDev/Gem/build/Development -F/Users/tigital/Library/Frameworks -filelist /Users/tigital/puredataDev/Gem/build/GEM_darwin.build/Development/gem_darwin.build/Objects-normal/ppc/Gem.LinkFileList -framework AGL -framework Carbon -framework GLUT -framework OpenGL -framework QuickTime -lftgl -arch ppc -Wl,-single_module -install_name @executable_path/../Resources/extra/Gem.pd_darwin -Wl,-Y,1455 -dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup -lz -lfreetype -Xlinker -Y -Xlinker 100
so should we change the configure-checks for Gem? to either use "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup" or - if this is not supported - "-bundle -undefined suppress -flat_namespace"
mfg.asdr IOhannes
On Sep 21, 2006, at 3:17 PM, IOhannes m zmoelnig wrote:
wow! do the change the preferred way of linking with every minor
release?i can understand that there might be some changes in the preferred loading mechanism after the macintel change (with the goal of
supporting both architectures). but afair, they only changed the fundamental architecture once in the last 10 years...
...well, to be fair, the switch was done with 10.3.x, which is about
4 years ago at this point...and look at this as a good thing, because
I remember everyone complaining in the pre-10.3 days about the lack
of dlopen() standardizing...
so should we change the configure-checks for Gem? to either use "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup" or - if this is not supported - "-bundle -undefined suppress -flat_namespace"
...it depends: I wouldn't do the check fully based on osx version,
but perhaps also include pd version, since I don't recall if the
older NSBundle stuff works with "dynamiclibs" or not...
...always keeping us on our toes...
jamie
james tittle wrote:
On Sep 21, 2006, at 3:17 PM, IOhannes m zmoelnig wrote:
wow! do the change the preferred way of linking with every minor release?
i can understand that there might be some changes in the preferred loading mechanism after the macintel change (with the goal of supporting both architectures). but afair, they only changed the fundamental architecture once in the last 10 years...
...well, to be fair, the switch was done with 10.3.x, which is about 4 years ago at this point...and look at this as a good thing, because I remember everyone complaining in the pre-10.3 days about the lack of dlopen() standardizing...
so it's just the pd-community that is lagging somewhat behind?
so should we change the configure-checks for Gem? to either use "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup" or - if this is not supported - "-bundle -undefined suppress -flat_namespace"
...it depends: I wouldn't do the check fully based on osx version, but perhaps also include pd version, since I don't recall if the older NSBundle stuff works with "dynamiclibs" or not...
but that pretty soon becomes ugly. afaik, dlopen() is the standard way of loading externals on osx at least since pd-0.39. since we are rapidely approaching pd-0.40 i guess we could just go and ignore previous versions. as for the os-x version: isn't 10.3 the minimum requirement for pd anyhow?
so the check as i currently do it is: "does the compiler support "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup"? if not, does it support "-bundle -undefined suppress -flat_namespace"? i hope this will just work in most cases.
...always keeping us on our toes...
good to see you back on yours: getting more lively, are ye ;-)
,fgasdr IOhannes
On Sep 21, 2006, at 3:53 PM, james tittle wrote:
On Sep 21, 2006, at 3:17 PM, IOhannes m zmoelnig wrote:
wow! do the change the preferred way of linking with every minor
release?i can understand that there might be some changes in the preferred loading mechanism after the macintel change (with the goal of
supporting both architectures). but afair, they only changed the fundamental architecture once in the last 10 years......well, to be fair, the switch was done with 10.3.x, which is
about 4 years ago at this point...and look at this as a good thing,
because I remember everyone complaining in the pre-10.3 days about
the lack of dlopen() standardizing...so should we change the configure-checks for Gem? to either use "-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup" or - if this is not supported - "-bundle -undefined suppress -flat_namespace"
...it depends: I wouldn't do the check fully based on osx version,
but perhaps also include pd version, since I don't recall if the
older NSBundle stuff works with "dynamiclibs" or not......always keeping us on our toes...
Shall we try building the whole of Pd-extended with these linker flags?
-dynamiclib -mmacosx-version-min=10.3 -undefined dynamic_lookup
.hc
If you are not part of the solution, you are part of the problem.
On Wed, 20 Sep 2006, chris clepper wrote:
On 9/20/06, Hans-Christoph Steiner hans@eds.org wrote:
Yes, on Mac OS X, the externals have to be built against a Pd that supports dlopen(), otherwise they won't work.
I think they just need to be built as dylib and not bundle. I have not tested 0.40 to confirm yet.
What's the difference between dylib and bundle supposed to be?
How do I compile something as a dylib instead of a bundle? (I rarely use OSX, but last time I tried I was on OSX 10.3 and/or 10.4 compiling libs with -bundle thinking that it's the equivalent of Linux's -shared)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sep 21, 2006, at 2:47 PM, Mathieu Bouchard wrote:
On Wed, 20 Sep 2006, chris clepper wrote:
On 9/20/06, Hans-Christoph Steiner hans@eds.org wrote:
Yes, on Mac OS X, the externals have to be built against a Pd that supports dlopen(), otherwise they won't work.
I think they just need to be built as dylib and not bundle. I
have not tested 0.40 to confirm yet.What's the difference between dylib and bundle supposed to be?
...from apple's docs:
"A bundle is a directory in the file system that groups related
resources together in one place. Applications, frameworks, and plug-
ins are all examples of bundles."
"...One way to reduce the file size and memory footprint of
applications is to reduce the amount of code that is loaded at
application launch. Dynamic libraries address this need; they can be
loaded either at application launch time or at runtime. Dynamic
libraries provide a way for applications to load code when it’s
actually needed."
...so conceptually, a bundle can be a dynamiclib, and much more, but
a dynamiclib is closest to a "shared library" in the linux sense...
How do I compile something as a dylib instead of a bundle? (I
rarely use OSX, but last time I tried I was on OSX 10.3 and/or 10.4
compiling libs with -bundle thinking that it's the equivalent of
Linux's -shared)
...did you see my previous emails in this thread?
jamie
-
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle -
Mathieu Bouchard -
Miller Puckette