From: Jennifer A. <jm...@co...> - 2010-10-04 20:56:39
|
This reply went out to Arlindo only, and I wanted the entire list to see it. --Jennifer Begin forwarded message: > From: Jennifer Adams <jm...@co...> > Date: October 4, 2010 4:22:17 PM EDT > To: Arlindo da Silva <da...@al...> > Subject: Re: [Opengrads-devel] Opengrads bundle 2.0.a9 being uploaded > > Arlindo, et al., > I'm glad to hear that 2.0.a9 is behaving well with opengrads. I have > not heard any complaints about a9 so far. As for the OS X builds, I > have not upgraded to snow leopard yet, but Brian has, so I will > likely be putting out three OS X releases next time. I will keep > doing the powerpc builds until one of the supplib upgrades breaks > something. > > Regarding the supplibs, I have been working on the switch to cairo > for graphics rendering. At the moment, I am only working in the mac > environment, using the macports installation of cairo, so I don't > really know what the issues are regarding building from source, or > for the autoconfiguration. If any of you can provide some guidance, > especially for the autoconf stuff, it would be most welcome. There > must be some existing code out there that does this, maybe already > in opengrads, but I haven't looked for it yet. > --Jennifer > > > > > On Oct 4, 2010, at 3:18 PM, Arlindo da Silva wrote: > >> All, >> >> I have finished merging COLA's latest 2.0.a9 with our code base >> and started uploading binaries to sf.net. Now that the colorized >> text feature is in COLA's codebase merging is becoming easier. The >> only thing I have to do is to add the hooks for the extensions >> which is localized in a couple of places, and some mods in the main >> grads.c mainly for the windows and java builds. (I am not >> distributing the java builds yet.) >> >> Not many updates in the extensions this time. As per Jennifer >> request, I have dropped the shape extension altogether (last time >> it was hidden, this time I didn't even build it.) I also had to >> make a small (but subtle) change in the LATS extension because of >> some internal change in the main grads codebase. This was good, the >> revised LATS is more robust this now. >> >> Snow Leopard update. I have a 99% functional build on Mac OS X >> 10.6 (Snow Leopard, 64 bits). All seems to work fine with the core >> grads functionality from COLA. I only have an issue with the LATS >> extension, in particular when writing GRIB-1 files -- the netcdf/ >> hdf output works just fine. I suspect it has something to do with >> the size of integers. Until I fix this I'll not release the SNow >> Leopard build. The good news for Jennifer is that her builds >> should work out of the box on SL. >> >> Jose, >> >> When you have a chance, could you make the FreeBSD builds? Thanks. >> >> Cheers, >> >> Arlindo >> >> -- >> Arlindo da Silva >> da...@al... >> ------------------------------------------------------------------------------ >> Virtualization is moving to the mainstream and overtaking non- >> virtualized >> environment for deploying applications. Does it make network security >> easier or more difficult to achieve? Read this whitepaper to >> separate the >> two and get a better understanding. >> http://p.sf.net/sfu/hp-phase2-d2d_______________________________________________ >> Opengrads-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opengrads-devel > > -- > Jennifer M. Adams > IGES/COLA > 4041 Powder Mill Road, Suite 302 > Calverton, MD 20705 > jm...@co... > > > -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
From: Patrice D. <per...@fr...> - 2010-10-05 10:02:12
|
On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote: > > > >Regarding the supplibs, I have been working on the switch to cairo > >for graphics rendering. At the moment, I am only working in the > >mac environment, using the macports installation of cairo, so I > >don't really know what the issues are regarding building from > >source, or for the autoconfiguration. If any of you can provide > >some guidance, especially for the autoconf stuff, it would be most > >welcome. There must be some existing code out there that does > >this, maybe already in opengrads, but I haven't looked for it yet. cairo uses pkgconfig. So something like cairo_pkgconfig=yes PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],, [cairo_pkgconfig=no]) should set CAIRO_LIBS and CAIRO_CFLAGS. This should be enough for linking dynamically against the system library. The libs it requires when statically linking should be listed in Requires.private:. To link statically against the supplibs, I guess that you have 2 options. Either simply supply the right link flags and include dirs, either hardcoded or using GA_SET_FLAGS and similar. Or put the .pc files obtained when compiling supplibs in a specific directory in the supplibs, set PKG_CONFIG_PATH to this directory, and use a pkg-config call, like pkg-config --static cairo --libs I don't know if you'd want to put pkg-config in the supplibs too, then, but, in case you wonder, on my debian squeeze box, pkg-config links against glib, which in turns requires libpcre, and no other dependency (besides a C library) seems to be involved. (Cairo, however needs quite a bit of depednecies, but it is not clear to me how you want to handle the backends of cairo? On my box, the xcb backend is used: pkg-config --static cairo --libs -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau -lXdmcp But I guess that on MacOSX the Quartz backend should be used, on Windows the win32 backend, on other UNIX the xlib backend?) -- Pat |
From: Arlindo da S. <da...@al...> - 2010-10-05 14:03:39
|
On Tue, Oct 5, 2010 at 5:16 AM, Patrice Dumas <per...@fr...> wrote: > On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote: > > > > > >Regarding the supplibs, I have been working on the switch to cairo > > >for graphics rendering. At the moment, I am only working in the > > >mac environment, using the macports installation of cairo, so I > > >don't really know what the issues are regarding building from > > >source, or for the autoconfiguration. If any of you can provide > > >some guidance, especially for the autoconf stuff, it would be most > > >welcome. There must be some existing code out there that does > > >this, maybe already in opengrads, but I haven't looked for it yet. > > cairo uses pkgconfig. So something like > > cairo_pkgconfig=yes > PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],, > [cairo_pkgconfig=no]) > > should set CAIRO_LIBS and CAIRO_CFLAGS. This should be enough for > linking dynamically against the system library. > > > The libs it requires when statically linking should be listed in > Requires.private:. To link statically against the supplibs, I guess that > you have 2 options. Either simply supply the right link flags and > include dirs, either hardcoded or using GA_SET_FLAGS and similar. Or > put the .pc files obtained when compiling supplibs in a specific > directory in the supplibs, set PKG_CONFIG_PATH to this directory, and > use a pkg-config call, like > pkg-config --static cairo --libs > > I don't know if you'd want to put pkg-config in the supplibs too, then, > but, in case you wonder, on my debian squeeze box, pkg-config links against > glib, which in turns requires libpcre, and no other dependency (besides > a C library) seems to be involved. > > > (Cairo, however needs quite a bit of depednecies, but it is not clear to me > how you want to handle the backends of cairo? On my box, the xcb backend > is used: > > pkg-config --static cairo --libs > -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm > -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau -lXdmcp > > But I guess that on MacOSX the Quartz backend should be used, on Windows > the win32 backend, on other UNIX the xlib backend?) > > Nice to hear form you! The opengrads supplibs includes pkg-config and builds (whenever possible) builds all packages with it. The main reason being this autoconf integration. As for my experience building cairo in the supplibs. This is the only library that I have *not* succeeded to build statically on all platforms. Not quite sure what the issues are. Since the opengrads wrappers automatically sets LD_LIBRARY_PATH, this have not been a problem. So far I have used cairo primarily for gxyat with only 4 backends: PNG, SVG, ps and pdf. I disable everything else to avoid any unnecessary dependency. Jennifer: which back ends do you intend to use? Arlindo -- Arlindo da Silva da...@al... |
From: Jennifer A. <jm...@co...> - 2010-10-05 15:37:35
|
Thanks for the comments. This is NOT my area of expertise, and I welcome your guidance. Clearly, the dynamic linking against system installations is the easiest, but for the binary distributions, I will have to figure out how to link statically. That long list of dependent libraries is daunting! In my simple test program (rmf.c), I am compiling/linking with this command: gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib - lcairo -L/usr/X11/lib -lX11 I have some more testing to do with fonts, and so I may have to add some more libs to that list, but if my code doesn't require all those dependent libs, I don't have to statically link them, do I? As for backends, I am planning to use cairo to draw to an X window, PNG, Postscript, PDF, and SVG. I do not see why it's necessary to add the platform-specific window backends; X has been working fine for GrADS all these years. --Jennifer On Oct 5, 2010, at 10:03 AM, Arlindo da Silva wrote: > > > On Tue, Oct 5, 2010 at 5:16 AM, Patrice Dumas <per...@fr...> > wrote: > On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote: > > > > > >Regarding the supplibs, I have been working on the switch to cairo > > >for graphics rendering. At the moment, I am only working in the > > >mac environment, using the macports installation of cairo, so I > > >don't really know what the issues are regarding building from > > >source, or for the autoconfiguration. If any of you can provide > > >some guidance, especially for the autoconf stuff, it would be most > > >welcome. There must be some existing code out there that does > > >this, maybe already in opengrads, but I haven't looked for it yet. > > cairo uses pkgconfig. So something like > > cairo_pkgconfig=yes > PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],, > [cairo_pkgconfig=no]) > > should set CAIRO_LIBS and CAIRO_CFLAGS. This should be enough for > linking dynamically against the system library. > > > The libs it requires when statically linking should be listed in > Requires.private:. To link statically against the supplibs, I guess > that > you have 2 options. Either simply supply the right link flags and > include dirs, either hardcoded or using GA_SET_FLAGS and similar. Or > put the .pc files obtained when compiling supplibs in a specific > directory in the supplibs, set PKG_CONFIG_PATH to this directory, and > use a pkg-config call, like > pkg-config --static cairo --libs > > I don't know if you'd want to put pkg-config in the supplibs too, > then, > but, in case you wonder, on my debian squeeze box, pkg-config links > against > glib, which in turns requires libpcre, and no other dependency > (besides > a C library) seems to be involved. > > > (Cairo, however needs quite a bit of depednecies, but it is not > clear to me > how you want to handle the backends of cairo? On my box, the xcb > backend > is used: > > pkg-config --static cairo --libs > -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm - > lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau - > lXdmcp > > But I guess that on MacOSX the Quartz backend should be used, on > Windows > the win32 backend, on other UNIX the xlib backend?) > > > Nice to hear form you! > > The opengrads supplibs includes pkg-config and builds (whenever > possible) builds all packages with it. The main reason being this > autoconf integration. > > As for my experience building cairo in the supplibs. This is the > only library that I have *not* succeeded to build statically on all > platforms. Not quite sure what the issues are. Since the opengrads > wrappers automatically sets LD_LIBRARY_PATH, this have not been a > problem. So far I have used cairo primarily for gxyat with only 4 > backends: PNG, SVG, ps and pdf. I disable everything else to avoid > any unnecessary dependency. > > Jennifer: which back ends do you intend to use? > > Arlindo > > -- > Arlindo da Silva > da...@al... > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb_______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
From: Arlindo da S. <da...@al...> - 2010-10-05 17:10:09
|
On Tue, Oct 5, 2010 at 11:37 AM, Jennifer Adams <jm...@co...> wrote: > Thanks for the comments. This is NOT my area of expertise, and I welcome > your guidance. Clearly, the dynamic linking against system installations is > the easiest, but for the binary distributions, I will have to figure out how > to link statically. That long list of dependent libraries is daunting! In my > simple test program (rmf.c), I am compiling/linking with this command: > > gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib -lcairo > -L/usr/X11/lib -lX11 > > I have some more testing to do with fonts, and so I may have to add some > more libs to that list, but if my code doesn't require all those dependent > libs, I don't have to statically link them, do I? > > At a minimum you *must* have: fontconfig, freetype, pixman; other libraries such as jpeg, libpng, etc., we already have. > As for backends, I am planning to use cairo to draw to an X window, PNG, > Postscript, PDF, and SVG. I do not see why it's necessary to add the > platform-specific window backends; X has been working fine for GrADS all > these years. > I'd love to be able to use a native Windows backend and get rid of the X server... The Quartz backend would also give it a more native look on Mac OS X, but that is less critical. So, if you could leave the door open to the possibility of an alternative to X that would be good. Arlindo > --Jennifer > > > On Oct 5, 2010, at 10:03 AM, Arlindo da Silva wrote: > > > > On Tue, Oct 5, 2010 at 5:16 AM, Patrice Dumas <per...@fr...> wrote: > >> On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote: >> > > >> > >Regarding the supplibs, I have been working on the switch to cairo >> > >for graphics rendering. At the moment, I am only working in the >> > >mac environment, using the macports installation of cairo, so I >> > >don't really know what the issues are regarding building from >> > >source, or for the autoconfiguration. If any of you can provide >> > >some guidance, especially for the autoconf stuff, it would be most >> > >welcome. There must be some existing code out there that does >> > >this, maybe already in opengrads, but I haven't looked for it yet. >> >> cairo uses pkgconfig. So something like >> >> cairo_pkgconfig=yes >> PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],, >> [cairo_pkgconfig=no]) >> >> should set CAIRO_LIBS and CAIRO_CFLAGS. This should be enough for >> linking dynamically against the system library. >> >> >> The libs it requires when statically linking should be listed in >> Requires.private:. To link statically against the supplibs, I guess that >> you have 2 options. Either simply supply the right link flags and >> include dirs, either hardcoded or using GA_SET_FLAGS and similar. Or >> put the .pc files obtained when compiling supplibs in a specific >> directory in the supplibs, set PKG_CONFIG_PATH to this directory, and >> use a pkg-config call, like >> pkg-config --static cairo --libs >> >> I don't know if you'd want to put pkg-config in the supplibs too, then, >> but, in case you wonder, on my debian squeeze box, pkg-config links >> against >> glib, which in turns requires libpcre, and no other dependency (besides >> a C library) seems to be involved. >> >> >> (Cairo, however needs quite a bit of depednecies, but it is not clear to >> me >> how you want to handle the backends of cairo? On my box, the xcb backend >> is used: >> >> pkg-config --static cairo --libs >> -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm >> -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau -lXdmcp >> >> But I guess that on MacOSX the Quartz backend should be used, on Windows >> the win32 backend, on other UNIX the xlib backend?) >> >> > Nice to hear form you! > > The opengrads supplibs includes pkg-config and builds (whenever possible) > builds all packages with it. The main reason being this autoconf > integration. > > As for my experience building cairo in the supplibs. This is the only > library that I have *not* succeeded to build statically on all platforms. > Not quite sure what the issues are. Since the opengrads wrappers > automatically sets LD_LIBRARY_PATH, this have not been a problem. So far I > have used cairo primarily for gxyat with only 4 backends: PNG, SVG, ps and > pdf. I disable everything else to avoid any unnecessary dependency. > > Jennifer: which back ends do you intend to use? > > Arlindo > > -- > Arlindo da Silva > da...@al... > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > > http://p.sf.net/sfu/beautyoftheweb_______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel > > > -- > Jennifer M. Adams > IGES/COLA > 4041 Powder Mill Road, Suite 302 > Calverton, MD 20705 > jm...@co... > > > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel > > -- Arlindo da Silva da...@al... |
From: Jennifer A. <jm...@co...> - 2010-10-05 17:56:14
|
On Oct 5, 2010, at 1:10 PM, Arlindo da Silva wrote: > > > On Tue, Oct 5, 2010 at 11:37 AM, Jennifer Adams <jm...@co...> > wrote: > Thanks for the comments. This is NOT my area of expertise, and I > welcome your guidance. Clearly, the dynamic linking against system > installations is the easiest, but for the binary distributions, I > will have to figure out how to link statically. That long list of > dependent libraries is daunting! In my simple test program (rmf.c), > I am compiling/linking with this command: > > gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib - > lcairo -L/usr/X11/lib -lX11 > > I have some more testing to do with fonts, and so I may have to add > some more libs to that list, but if my code doesn't require all > those dependent libs, I don't have to statically link them, do I? > > > At a minimum you *must* have: fontconfig, freetype, pixman; other > libraries such as jpeg, libpng, etc., we already have. Well, this is a basic question, but why don't I have to add -lpng12 to my test program if it is writing out PNG files? Is that somehow bundled into the macports version of libcairo.a? > > As for backends, I am planning to use cairo to draw to an X window, > PNG, Postscript, PDF, and SVG. I do not see why it's necessary to > add the platform-specific window backends; X has been working fine > for GrADS all these years. > > I'd love to be able to use a native Windows backend and get rid of > the X server... You can do whatever you want with the Windows builds. I don't want to hold you back you from making Windows builds easier to generate and use, but I am an MS nothing, and I can't support Windows code, so it'll have to be an opengrads feature. We haven't implemented anything in GrADS yet, but I don't see how we could close the door on the possibility of alternatives to X. > The Quartz backend would also give it a more native look on Mac OS > X, but that is less critical. Yeah, I really don't care about that as long as X11 is supported in OS X. --Jennifer |
From: Patrice D. <per...@fr...> - 2010-10-05 20:36:52
|
On Tue, Oct 05, 2010 at 11:37:27AM -0400, Jennifer Adams wrote: > will have to figure out how to link statically. That long list of > dependent libraries is daunting! In my simple test program (rmf.c), > I am compiling/linking with this command: > > gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib - > lcairo -L/usr/X11/lib -lX11 Indeed, with gcc, you only need to link dynamically against a library when you use a symbol from that library. But The library itself may need more symbols. When linking dynamically, you don't need to care, taking care of all the library dynamic dependency is the dynamic linker job. When you link statically, you have to do the job of the dynamic linker yourself, so that you need to supply all the libraries indirectly needed. > I have some more testing to do with fonts, and so I may have to add > some more libs to that list, but if my code doesn't require all > those dependent libs, I don't have to statically link them, do I? If the library you use require those dependent libs, you have to statically link them, even if your conde don't require them... You can laso link some libraries statically, and other dynamically. For example, the X libraries may be linked dynamically, even when most of th eother libraries are statically linked, and, unless I am wrong it is what is done for grads/opengrads. > As for backends, I am planning to use cairo to draw to an X window, > PNG, Postscript, PDF, and SVG. I do not see why it's necessary to > add the platform-specific window backends; X has been working fine > for GrADS all these years. Beware that there are 2 X backends: * xlib: Uses the Xlib interface to the X Window System. This backend can target Windows or Pixmaps. The Render extension is used if available, but is not required. * xcb: Provides support similar to the xlib backend, but uses the XCB interface rather than Xlib. I guess that for maximal portability you should use the xlib backend when compiling cairo, and not the xcb backend. -- Pat |
From: Jennifer A. <jm...@co...> - 2010-10-06 00:02:20
|
Pat, That is a very helpful explanation! I will be more appreciative of my dynamic linker from now on. I will also try linking my test program statically and see what libraries I am going to have to add manually to get it to work. You are correct, we do dynamically link with X11, since we assume that is installed on every system where users are running GrADS. As for cairo, it seems like we should use xlib and not xcb. I am not expecting to have to change a lot of code in gxX.c, but I'll know better when we are done testing with stand-alone programs and are ready to begin integrating cairo into GrADS. --Jennifer On Oct 5, 2010, at 4:36 PM, Patrice Dumas wrote: > On Tue, Oct 05, 2010 at 11:37:27AM -0400, Jennifer Adams wrote: >> will have to figure out how to link statically. That long list of >> dependent libraries is daunting! In my simple test program (rmf.c), >> I am compiling/linking with this command: >> >> gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib - >> lcairo -L/usr/X11/lib -lX11 > > Indeed, with gcc, you only need to link dynamically against a > library when you use a symbol from that library. But The library > itself may need more symbols. When linking dynamically, you don't > need > to care, taking care of all the library dynamic dependency is the > dynamic linker job. > > When you link statically, you have to do the job of the dynamic linker > yourself, so that you need to supply all the libraries indirectly > needed. > >> I have some more testing to do with fonts, and so I may have to add >> some more libs to that list, but if my code doesn't require all >> those dependent libs, I don't have to statically link them, do I? > > If the library you use require those dependent libs, you have to > statically link them, even if your conde don't require them... > You can laso link some libraries statically, and other dynamically. > For example, the X libraries may be linked dynamically, even when > most of th eother libraries are statically linked, and, unless I am > wrong it is what is done for grads/opengrads. > >> As for backends, I am planning to use cairo to draw to an X window, >> PNG, Postscript, PDF, and SVG. I do not see why it's necessary to >> add the platform-specific window backends; X has been working fine >> for GrADS all these years. > > Beware that there are 2 X backends: > > * xlib: Uses the Xlib interface to the X Window System. This backend > can target Windows or Pixmaps. The Render extension is used if > available, but is not required. > > * xcb: Provides support similar to the xlib backend, but uses the > XCB interface rather than Xlib. > > I guess that for maximal portability you should use the xlib backend > when compiling cairo, and not the xcb backend. > > -- > Pat > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |