From jules at codesourcery.com Tue Feb 3 14:08:11 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 03 Feb 2009 09:08:11 -0500 Subject: [patch] Guard IPP 5.0 benchmark dependency Message-ID: <49884FCB.6040003@codesourcery.com> Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ipp-fft.diff URL: From jules at codesourcery.com Thu Feb 5 17:03:06 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 05 Feb 2009 12:03:06 -0500 Subject: [patch] Use ALF inout buffers for ukernels Message-ID: <498B1BCA.3090302@codesourcery.com> First step towards merging ukernels into the overlay kernel. Because alf_base.hpp contains all the ALF glue for the SPU side, none of the ukernels themselves need to change. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ukio.diff URL: From stefan at codesourcery.com Thu Feb 5 17:21:56 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 05 Feb 2009 12:21:56 -0500 Subject: [vsipl++] [patch] Use ALF inout buffers for ukernels In-Reply-To: <498B1BCA.3090302@codesourcery.com> References: <498B1BCA.3090302@codesourcery.com> Message-ID: <498B2034.6000905@codesourcery.com> Jules Bergmann wrote: > First step towards merging ukernels into the overlay kernel. > > Because alf_base.hpp contains all the ALF glue for the SPU side, none of > the ukernels themselves need to change. > > Ok to apply? This looks fine. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Fri Feb 13 16:16:31 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 13 Feb 2009 11:16:31 -0500 Subject: [patch] Fix quickstart manual building instructions Message-ID: <49959CDF.6080600@codesourcery.com> Ok to apply? -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qs.diff URL: From stefan at codesourcery.com Fri Feb 13 16:23:10 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 13 Feb 2009 11:23:10 -0500 Subject: [vsipl++] [patch] Fix quickstart manual building instructions In-Reply-To: <49959CDF.6080600@codesourcery.com> References: <49959CDF.6080600@codesourcery.com> Message-ID: <49959E6E.70606@codesourcery.com> Jules Bergmann wrote: > Ok to apply? Yes, good catch ! Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Fri Feb 13 16:43:12 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 13 Feb 2009 11:43:12 -0500 Subject: [patch] Fix MPI configury Message-ID: <4995A320.9010804@codesourcery.com> We were always claiming to have MPI in the makefiles. Patch applied. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: par.diff URL: From jules at codesourcery.com Thu Feb 19 16:56:39 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 19 Feb 2009 11:56:39 -0500 Subject: [patch] Add enable_timer option to recommended Cell setup Message-ID: <499D8F47.4090603@codesourcery.com> Patch applied. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: update-setup.diff URL: From brooks at codesourcery.com Thu Feb 19 17:01:03 2009 From: brooks at codesourcery.com (Brooks Moses) Date: Thu, 19 Feb 2009 09:01:03 -0800 Subject: [vsipl++] [patch] Add enable_timer option to recommended Cell setup In-Reply-To: <499D8F47.4090603@codesourcery.com> References: <499D8F47.4090603@codesourcery.com> Message-ID: <499D904F.4010700@codesourcery.com> Jules Bergmann wrote, at 2/19/2009 8:56 AM: > Patch applied. I was just noticing this bit in there: > +$src_dir/configure \ > + --with-cbe-sdk=3.0 \ We no longer check the value supplied as an argument to --with-cbe-sdk, so this should just be --with-cbe-sdk. We also probably need to update the documentation to reflect this. - Brooks From jules at codesourcery.com Thu Feb 19 17:10:11 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 19 Feb 2009 12:10:11 -0500 Subject: [vsipl++] [patch] Add enable_timer option to recommended Cell setup In-Reply-To: <499D904F.4010700@codesourcery.com> References: <499D8F47.4090603@codesourcery.com> <499D904F.4010700@codesourcery.com> Message-ID: <499D9273.9050700@codesourcery.com> > We no longer check the value supplied as an argument to --with-cbe-sdk, > so this should just be --with-cbe-sdk. We also probably need to update > the documentation to reflect this. Thanks Brooks! Patch applied. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: update-setup2.diff URL: From howes at ll.mit.edu Thu Feb 19 21:33:44 2009 From: howes at ll.mit.edu (Brad Howes) Date: Thu, 19 Feb 2009 16:33:44 -0500 Subject: Possible Threading Issue Message-ID: <2D341D5B-28C3-4C7B-8411-5497053C02AE@ll.mit.edu> All, Are there some guidelines for using VSIPL++ (vsipl-lite-2.0) in a threaded environment? I'm seeing some bizarre behavior when trying to allocate a new vsip::Vector. The main thread starts up with vsip::vsipl vpp( argc, argv ); and then later spawns a worker thread. In that worker thread, I try: new vsip::Vector( 1000, 0.0 ) and I get a NULL pointer for a Memory_pool object. This pool object is from an map reference that has all NULL attribute values. Below is the stack trace, for what it is worth. Any ideas would be most appreciated. Thanks in advance! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 [Switching to process 27854 thread 0x2703] 0x00d11cb9 in vsip::impl::Memory_pool::allocate (this=0x0, size=3000) at memory_pool.hpp:50 50 { return (T*)(impl_allocate(size * sizeof(T))); } (gdb) bt #0 0x00d11cb9 in vsip::impl::Memory_pool::allocate (this=0x0, size=3000) at memory_pool.hpp:50 #1 0x00d11d02 in vsip::impl::Dense_storage::Dense_storage (this=0xc56190, pool=0x0, size=3000, val=0, buffer=0x0) at dense.hpp:321 #2 0x00d11db7 in vsip::impl::Dense_impl<1u, float, vsip::tuple<0u, 1u, 2u>, vsip::impl::Cmplx_inter_fmt, vsip::Local_map>::Dense_impl (this=0xc56190, dom=@0xb0102b14, val=0, map=@0xb0102c50) at dense.hpp: 1381 #3 0x00d1220e in vsip::Dense<1u, float, vsip::tuple<0u, 1u, 2u>, vsip::Local_map>::Dense (this=0xc56190, dom=@0xb0102b14, value=0, map=@0xb0102c50) at dense.hpp:644 #4 0x00d1228b in vsip::const_Vector, vsip::Local_map> >::const_Vector (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at vector.hpp:75 #5 0x00d12308 in vsip::impl_View, vsip::Local_map>, float, 1u>::impl_View (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at view_traits.hpp:244 #6 0x00d12338 in vsip::Vector, vsip::Local_map> >::Vector (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at vector.hpp:197 #7 0x00d0888e in SideCar::Algorithms::NCIntegrate::process (this=0xc24180, msg=@0xb0102d58) at /Users/howes/sidecar/trunk/ Algorithms/ncintegrate/NCIntegrate.cc:86 #8 0x00d0f9b3 in boost::_mfi::mf1 const&>::operator() (this=0xb0102d14, p=0xc24180, a1=@0xb0102d58) at bind/mem_fn_template.hpp:162 #9 0x00d10beb in boost::detail::function::function_mem_invoker2 const&), bool, SideCar::Algorithms::NCIntegrate*, SideCar::Messages::TPRIMessageRef >::invoke (function_obj_ptr=@0xc23a8c, a0=0xc24180, a1=@0xb0102d58) at function/ function_template.hpp:206 #10 0x00d17b88 in boost::function2 >::operator() (this=0xc23a88, a0=0xc24180, a1=@0xb0102d90) at function/function_template.hpp:989 #11 0x00d18269 in SideCar::Algorithms::TProcessor::process (this=0xc23a80, msg=@0xb0102e38) at Processor.h:64 #12 0x0008ae8a in SideCar::Algorithms::Algorithm::process (this=0xc24180, msg=@0xb0102e38, channelIndex=0) at /Users/howes/ sidecar/trunk/Algorithms/Algorithm.cc:139 #13 0x00096867 in SideCar::Algorithms::Controller::processDataMessage (this=0xc1a360, data=0xb92e20) at /Users/howes/sidecar/trunk/ Algorithms/Controller.cc:360 #14 0x003cbd9f in SideCar::IO::Task::processMessage (this=0xc1a360, data=0xb92e20) at /Users/howes/sidecar/trunk/IO/Task.cc:484 #15 0x00095dca in SideCar::Algorithms::Controller::processOneMessage (this=0xc1a360, data=0xb92e20) at /Users/howes/sidecar/trunk/ Algorithms/Controller.cc:490 #16 0x00095f6d in SideCar::Algorithms::Controller::svc (this=0xc1a360) at /Users/howes/sidecar/trunk/Algorithms/Controller.cc:511 #17 0x0094af8d in ACE_Task_Base::svc_run (args=0xc1a360) at Task.cpp:275 #18 0x0094b354 in ACE_Thread_Adapter::invoke (this=0xc246f0) at Thread_Adapter.cpp:98 #19 0x9610a095 in _pthread_start () #20 0x96109f52 in thread_start () -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 From jules at codesourcery.com Fri Feb 20 14:15:47 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 20 Feb 2009 09:15:47 -0500 Subject: [vsipl++] Possible Threading Issue In-Reply-To: <2D341D5B-28C3-4C7B-8411-5497053C02AE@ll.mit.edu> References: <2D341D5B-28C3-4C7B-8411-5497053C02AE@ll.mit.edu> Message-ID: <499EBB13.3070800@codesourcery.com> Brad, Sourcery VSIPL++ is not implicitly thread safe. The primary place for race conditions is the reference counting associated with blocks. Also, library initialization and use of backends may not be thread safe. However, if you're careful (initialize the library once, keep blocks local to a thread or protect actions that change the reference count of a shared block), things should work. The error you're getting typically occurs if VSIPL++ hasn't been initialized. If VSIPL++ is initialized, and if the threads share their global address space, something else must be clearing that default pool somehow. Can you try the following simple test program? If it works, it won't tell us much, but if it fails ... thanks, -- Jules Brad Howes wrote: > All, > > Are there some guidelines for using VSIPL++ (vsipl-lite-2.0) in a > threaded environment? I'm seeing some bizarre behavior when trying to > allocate a new vsip::Vector. The main thread starts up with > > vsip::vsipl vpp( argc, argv ); > > and then later spawns a worker thread. In that worker thread, I try: > > new vsip::Vector( 1000, 0.0 ) > > and I get a NULL pointer for a Memory_pool object. This pool object is > from an map reference that has all NULL attribute values. Below is the > stack trace, for what it is worth. Any ideas would be most appreciated. > Thanks in advance! > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 > [Switching to process 27854 thread 0x2703] > 0x00d11cb9 in vsip::impl::Memory_pool::allocate (this=0x0, > size=3000) at memory_pool.hpp:50 > 50 { return (T*)(impl_allocate(size * sizeof(T))); } > (gdb) bt > #0 0x00d11cb9 in vsip::impl::Memory_pool::allocate (this=0x0, > size=3000) at memory_pool.hpp:50 > #1 0x00d11d02 in vsip::impl::Dense_storage float>::Dense_storage (this=0xc56190, pool=0x0, size=3000, val=0, > buffer=0x0) at dense.hpp:321 > #2 0x00d11db7 in vsip::impl::Dense_impl<1u, float, vsip::tuple<0u, 1u, > 2u>, vsip::impl::Cmplx_inter_fmt, vsip::Local_map>::Dense_impl > (this=0xc56190, dom=@0xb0102b14, val=0, map=@0xb0102c50) at dense.hpp:1381 > #3 0x00d1220e in vsip::Dense<1u, float, vsip::tuple<0u, 1u, 2u>, > vsip::Local_map>::Dense (this=0xc56190, dom=@0xb0102b14, value=0, > map=@0xb0102c50) at dense.hpp:644 > #4 0x00d1228b in vsip::const_Vector vsip::tuple<0u, 1u, 2u>, vsip::Local_map> >::const_Vector > (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at > vector.hpp:75 > #5 0x00d12308 in vsip::impl_View vsip::tuple<0u, 1u, 2u>, vsip::Local_map>, float, 1u>::impl_View > (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at > view_traits.hpp:244 > #6 0x00d12338 in vsip::Vector vsip::tuple<0u, 1u, 2u>, vsip::Local_map> >::Vector (this=0xc5c090, > len=3000, value=@0xb0102c4c, map=@0xb0102c50) at vector.hpp:197 > #7 0x00d0888e in SideCar::Algorithms::NCIntegrate::process > (this=0xc24180, msg=@0xb0102d58) at > /Users/howes/sidecar/trunk/Algorithms/ncintegrate/NCIntegrate.cc:86 > #8 0x00d0f9b3 in boost::_mfi::mf1 SideCar::Algorithms::NCIntegrate, > SideCar::Messages::TPRIMessageRef > const&>::operator() (this=0xb0102d14, p=0xc24180, a1=@0xb0102d58) at > bind/mem_fn_template.hpp:162 > #9 0x00d10beb in boost::detail::function::function_mem_invoker2 (SideCar::Algorithms::NCIntegrate::*)(SideCar::Messages::TPRIMessageRef > const&), bool, SideCar::Algorithms::NCIntegrate*, > SideCar::Messages::TPRIMessageRef >::invoke > (function_obj_ptr=@0xc23a8c, a0=0xc24180, a1=@0xb0102d58) at > function/function_template.hpp:206 > #10 0x00d17b88 in boost::function2 SideCar::Algorithms::NCIntegrate*, > SideCar::Messages::TPRIMessageRef > >::operator() (this=0xc23a88, a0=0xc24180, a1=@0xb0102d90) at > function/function_template.hpp:989 > #11 0x00d18269 in > SideCar::Algorithms::TProcessor SideCar::Messages::Video>::process (this=0xc23a80, msg=@0xb0102e38) at > Processor.h:64 > #12 0x0008ae8a in SideCar::Algorithms::Algorithm::process > (this=0xc24180, msg=@0xb0102e38, channelIndex=0) at > /Users/howes/sidecar/trunk/Algorithms/Algorithm.cc:139 > #13 0x00096867 in SideCar::Algorithms::Controller::processDataMessage > (this=0xc1a360, data=0xb92e20) at > /Users/howes/sidecar/trunk/Algorithms/Controller.cc:360 > #14 0x003cbd9f in SideCar::IO::Task::processMessage (this=0xc1a360, > data=0xb92e20) at /Users/howes/sidecar/trunk/IO/Task.cc:484 > #15 0x00095dca in SideCar::Algorithms::Controller::processOneMessage > (this=0xc1a360, data=0xb92e20) at > /Users/howes/sidecar/trunk/Algorithms/Controller.cc:490 > #16 0x00095f6d in SideCar::Algorithms::Controller::svc (this=0xc1a360) > at /Users/howes/sidecar/trunk/Algorithms/Controller.cc:511 > #17 0x0094af8d in ACE_Task_Base::svc_run (args=0xc1a360) at Task.cpp:275 > #18 0x0094b354 in ACE_Thread_Adapter::invoke (this=0xc246f0) at > Thread_Adapter.cpp:98 > #19 0x9610a095 in _pthread_start () > #20 0x96109f52 in thread_start () > -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- A non-text attachment was scrubbed... Name: x-pthreads.cpp Type: text/x-c++src Size: 2044 bytes Desc: not available URL: From howes at ll.mit.edu Fri Feb 20 21:34:55 2009 From: howes at ll.mit.edu (Brad Howes) Date: Fri, 20 Feb 2009 16:34:55 -0500 Subject: [vsipl++] Possible Threading Issue In-Reply-To: <499EBB13.3070800@codesourcery.com> References: <2D341D5B-28C3-4C7B-8411-5497053C02AE@ll.mit.edu> <499EBB13.3070800@codesourcery.com> Message-ID: <3E40898F-ACCF-4FE9-A7F2-6F636F602B4B@ll.mit.edu> On Feb 20, 2009, at 9:15 AM, Jules Bergmann wrote: > The error you're getting typically occurs if VSIPL++ hasn't been > initialized. If VSIPL++ is initialized, and if the threads share > their > global address space, something else must be clearing that default > pool > somehow. Jules, thanks for the info. I *think* the problem is how our DSP framework loads algorithms, and this may only be a problem on MacOS X systems. We have one application that reads in an XML file and dynamically loads in various algorithm DLLs depending on the signal processing chain defined in the XML file. Our application definitely has the proper VSIPL++ initialization, but I think what is happening is that due to the static linkage of the VSIPL++ library, there might be multiple copies of some of the VSIPL++ symbols, one set in the DLL and another in our application binary. When we load the DLL via dlopen(), I'm not sure what VSIPL symbols are being used or initialized. Note that there could be multiple algorithm DLLs loaded by the application depending on the XML configuration. My workaround for MacOS X that seems to work is to build libsvpp and libvsip_csl as dynamic libraries instead of archives. There may be some Darwin-specific g++ or ld flags I could use with the static archives to fix my problem, but I'm not that familiar with the nuances of shared libraries under Darwin. Regards, Brad -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 From jules at codesourcery.com Tue Feb 24 13:58:38 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 24 Feb 2009 08:58:38 -0500 Subject: [patch] In-objdir makefile for SSAR Message-ID: <49A3FD0E.3010401@codesourcery.com> This allows SSAR to be built in the objdir (facilitating development). Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssar.diff URL: From jules at codesourcery.com Fri Feb 27 22:10:23 2009 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 27 Feb 2009 17:10:23 -0500 Subject: [patch] Building VSIPL++ shared libraries Message-ID: <49A864CF.3080706@codesourcery.com> Ok to apply? -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: so.diff URL: From brooks at codesourcery.com Fri Feb 27 22:24:38 2009 From: brooks at codesourcery.com (Brooks Moses) Date: Fri, 27 Feb 2009 14:24:38 -0800 Subject: [vsipl++] [patch] Building VSIPL++ shared libraries In-Reply-To: <49A864CF.3080706@codesourcery.com> References: <49A864CF.3080706@codesourcery.com> Message-ID: <49A86826.9030505@codesourcery.com> Jules Bergmann wrote, at 2/27/2009 2:10 PM: > Ok to apply? Given that this is indeed building multiple shared libraries, it seems odd for the option to be '--enable-shared-lib' in the singular form, not the plural '--enable-shared-libs'. Also, do we want to do versioned versions of the .so files? The usual habit from IBM's libraries is to create library.so.X.Y.Z as the actual library (where X.Y.Z is the version number), and install library.so.X and library.so as symlinks to it. They also include a linker options of "-shared -Wl,-soname=library.so.X" when linking the library; the -shared part might be redundant but the soname is probably a good idea, as it (may) enable programs to throw helpful runtime errors if the wrong version of the library is installed. Also, a couple of specific comments: > Index: GNUmakefile.in > =================================================================== > --- GNUmakefile.in (revision 236492) > +++ GNUmakefile.in (working copy) > @@ -88,8 +88,6 @@ > AR := @AR@ > # The path to the C compiler. > CC := @CC@ > -# C compilation flags. > -CFLAGS := @CFLAGS@ > # C preprocessor flags. > CPPFLAGS := @CPPFLAGS@ > # The path to the C compiler. What's the purpose of this change? It seems unrelated. > + > + > + > + > + Build shared libraries as well as static libraries. This > + requires that position independent code be generated, > + which may reduce performance. > + > + > + Yay for updating the documentation in the same patch! :) This looks good, except that that should be "position-independent code" with a hyphen. - Brooks From stefan at codesourcery.com Fri Feb 27 22:33:50 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 27 Feb 2009 17:33:50 -0500 Subject: [vsipl++] [patch] Building VSIPL++ shared libraries In-Reply-To: <49A864CF.3080706@codesourcery.com> References: <49A864CF.3080706@codesourcery.com> Message-ID: <49A86A4E.9090801@codesourcery.com> Jules Bergmann wrote: > Ok to apply? Jules, overall this looks fine. I have one high-level question (at the end), as well as a couple of specific comments / questions. > +if test "x$BUILD_SHARED_LIB" != "x"; then > + CXXFLAGS="-fPIC $CXXFLAGS" > + CFLAGS="-fPIC $CFLAGS" > +fi I think the above should be further conditionalized so it only applies when we are dealing with GCC. (I believe autoconf defines $GCC to 'yes' in that case.) > +debuglib: > + echo LIBS: $LIBS Did you mean to leave this in ? > define link_app > @echo linking $@ > $(CXX) $(LDFLAGS) $(call dir_var,$(dir $<),LDFLAGS) -o $@ $^ \ > - -Llib -lsvpp $(call dir_var,$(dir $<),LIBS) $(LIBS) > + $(call dir_var,$(dir $<),LIBS) $(LIBS) > endef Where does the link command get -lsvpp from after this change ? > hdr += $(patsubst $(srcdir)/src/%, %, \ > - $(wildcard $(srcdir)/src/vsip/opt/cuda/*.hpp)) > -hdr += $(patsubst $(srcdir)/src/%, %, \ > $(wildcard $(srcdir)/src/vsip/opt/diag/*.hpp)) > After you take cuda out of $hdr, would dependency generation still work with CUDA enabled ? (It looks like instead of removing the above, we should decorate it with #ifdef SOME_CUDA_VARIABLE ... #endif no ? > +ifdef BUILD_SHARED_LIB > +libs += lib/libsvpp.so > +lib_svpp := lib/libsvpp.so > +else > +lib_svpp := lib/libsvpp.$(LIBEXT) > +endif This raises an interesting question: Are we ever going to ship a DSO-only build variant ? With DSOs enabled, I would expect us to provide both, libsvpp.a, as well as libsvpp.so. (Note that this makes compilation slightly more complex, as then we have to build two sets of objects, one with -fPIC and one without. But the alternative, adding more build variants, sounds even worse, as far as build times and memory footprints are concerned. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Fri Feb 27 22:37:14 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 27 Feb 2009 17:37:14 -0500 Subject: [vsipl++] [patch] Building VSIPL++ shared libraries In-Reply-To: <49A86826.9030505@codesourcery.com> References: <49A864CF.3080706@codesourcery.com> <49A86826.9030505@codesourcery.com> Message-ID: <49A86B1A.2060506@codesourcery.com> Brooks Moses wrote: > Also, do we want to do versioned versions of the .so files? The usual > habit from IBM's libraries is to create library.so.X.Y.Z as the actual > library (where X.Y.Z is the version number), and install library.so.X > and library.so as symlinks to it. I don't expect this to be necessary, as we don't install libraries into common directories. And, we haven't talked about API/ABI compatibility yet, so right now two distinct releases are conceptually two distinct products. Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718