On Sat, 2005-08-13 at 16:18 -0400, Faheem Mitha wrote: > > On Thu, 11 Aug 2005, Adam C Powell IV wrote: > > > On Fri, 2005-07-15 at 21:38 -0400, Faheem Mitha wrote: > >> > >> On Mon, 11 Jul 2005, Adam C Powell IV wrote: > > >>> I don't understand what they mean by "dynamic" libraries either. I > >>> believe this is their mechanism for runtime loading of libraries as > >>> needed, without the requirement of linking all needed libraries to the > >>> binary. > >> > >>> I can see how this might be helpful for python, but for C(++), the > >>> needed libraries are pretty clear at compile time. So I've ignored > >>> this. (Also, didn't know that PETSc 2.x has python bindings...) > >> > >> When you say you've ignored this, do you mean that you have switched > >> off the dynamic libraies, "dynamic=0", or something else? > >> > >> One clearly has to do something, since the default way of making the > >> libraries causes problems if you move them. > > > > I get rid of the rpath, so moving them causes no problems. (rpath also > > violates Debian policy.) > > I don't understand what you mean. Do you mean that the PETSc developers > are using rpath to do this dynamic/shared business, and you have patched > the sources, or something like that? > > In any case, are you generating both the 'dynamic' and 'shared' libraries? > > In any case, does your package work with the Python 2.x bindings? I think > that these bindings require the 'dynamic' libraries.
I'm only generating 'shared' libraries, and not (yet) packaging Python bindings (didn't even know they exist). > >>>> At the moment it seems possible that I will be using DOLFIN > >>>> (www.fenics.org/dolfin) in my work. If this happens, I will be building > >>>> (and possibily maintaining) Debian packages for DOLFIN, and possibly > >>>> for some of the other associated libraries. In that event, I might need > >>>> your help in having these packages build against PETSc. This may not be > >>>> so easy, since some things about PETSc are non-standard. I hope that is > >>>> cool. > >> > >>> You mean, since some things about the Debian PETSc package are > >>> non-standard? I'm glad to help, once I can get petsc 2.3 in. > >> > >> No I meant that PETSc itself is non-standard. I assume the Debian > >> package will be as standard as possible, given that. :-) > >> > >> Faheem. > > > > Indeed. Thanks for your understanding. :-) > > > > I'll have some time next Tuesday to work on this, and hope to be able to > > upload packages at that time. > > I've reworked the PETSc 2.2.1 package recently. I have not uploaded the > reworked package to the apt repository, since I still need to rework the > DOLFIN package, and the reworked PETSc package breaks the current DOLFIN > package. > > However, all the changes are in the Debian directory, so I can send you > the debian/ directory as a tar.gz or something if you want. I could > alternatively put the revised PETSc 2.2.1 into the repository, calling it > by a different name or something. > > Let me know. Great, that would be very helpful. I'd really like to go straight to 2.3.0 but I'm sure your experience with BuildSystem in 2.2.1 would be very helpful toward that end! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
