Re: [Fink-devel] Shlibs field and variants
Hi Dan, On Jun 5, 2007, at 8:59 PM, Daniel Macks wrote: On Fri, Jun 01, 2007 at 07:19:47PM -0500, Remi Mommsen wrote: Thanks for implementing this feature. I gave it a try and it seems to mostly work. There is an issue with the validation when running with 'fink -m' when it comes to validating the deb directories: Validating .deb dir /sw/src/fink.build/root-root5- shlibs-5.14.00e-3... Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it does not exist! Removing runtime build-lock... Removing build-lock package... These shlibs do indeed not exists and are protected by the conditional. Here's a snippet of the shlibs field: (%type_pkg[-cernlib]) %p/lib/root/libEGPythia6.5.dylib 5.0.0 %n (=5.02.00-1) (%type_pkg[-geant4]) %p/lib/root/libG4root.5.dylib 5.0.0 %n (=5.14.00-1) (%type_pkg[-qt]) %p/lib/root/libGQt.5.dylib 5.0.0 %n (=5.15.04-2) %p/lib/root/libGX11.5.dylib 5.0.0 %n (=5.02.00-1) %p/lib/root/libGX11TTF.5.dylib 5.0.0 %n (=5.02.00-1) (%type_pkg[-cernlib]) %p/lib/root/libHbook.5.dylib 5.0.0 %n (=5.02.00-1) %p/lib/root/libHist.5.dylib 5.0.0 %n (=5.02.00-1) Interesting to note is that the validation does not complain about the libraries which are only built by the '-qt' variant (and which are missing, too). I guess, that is connected to the order of the type field: Type: -cernlib (boolean), -geant4 (boolean), -qt (boolean) i.e. it looks like that only the last conditional is taken into account. I copied the current version of the root5-devel info and patch file to: http://www-clued0.fnal.gov/~mommsen/fink/ That .info doesn't match the validator results you cited. Could you please show us a .info (and also the .deb itself) and the validator results for it? Shlibs data is stored in the .deb and the .deb validator reads it from there, not from the .info, so need to figure out whether the bug is in the .info parser (during compiling the .deb) or in the validator, or in some weird typo or expectation of how something should work. Sorry for the confusion. You are correct, I messed it up using root5 instead of root5-devel. The former does not have the conditional shlib field entries, yet. Remi -- No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced. * Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of Manchester URL:http://cern.ch/mommsen Fermilab, MS 357 voice:++1 (630) 840-8321 P.O. Box 500 fax:++1 (630) 840-2649 Batavia, Il 60510, US home:++1 (630) 236-0932 * - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
On Fri, Jun 01, 2007 at 07:19:47PM -0500, Remi Mommsen wrote: Thanks for implementing this feature. I gave it a try and it seems to mostly work. There is an issue with the validation when running with 'fink -m' when it comes to validating the deb directories: Validating .deb dir /sw/src/fink.build/root-root5-shlibs-5.14.00e-3... Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it does not exist! Removing runtime build-lock... Removing build-lock package... These shlibs do indeed not exists and are protected by the conditional. Here's a snippet of the shlibs field: (%type_pkg[-cernlib]) %p/lib/root/libEGPythia6.5.dylib 5.0.0 %n (=5.02.00-1) (%type_pkg[-geant4]) %p/lib/root/libG4root.5.dylib 5.0.0 %n (=5.14.00-1) (%type_pkg[-qt]) %p/lib/root/libGQt.5.dylib 5.0.0 %n (=5.15.04-2) %p/lib/root/libGX11.5.dylib 5.0.0 %n (=5.02.00-1) %p/lib/root/libGX11TTF.5.dylib 5.0.0 %n (=5.02.00-1) (%type_pkg[-cernlib]) %p/lib/root/libHbook.5.dylib 5.0.0 %n (=5.02.00-1) %p/lib/root/libHist.5.dylib 5.0.0 %n (=5.02.00-1) Interesting to note is that the validation does not complain about the libraries which are only built by the '-qt' variant (and which are missing, too). I guess, that is connected to the order of the type field: Type: -cernlib (boolean), -geant4 (boolean), -qt (boolean) i.e. it looks like that only the last conditional is taken into account. I copied the current version of the root5-devel info and patch file to: http://www-clued0.fnal.gov/~mommsen/fink/ That .info doesn't match the validator results you cited. Could you please show us a .info (and also the .deb itself) and the validator results for it? Shlibs data is stored in the .deb and the .deb validator reads it from there, not from the .info, so need to figure out whether the bug is in the .info parser (during compiling the .deb) or in the validator, or in some weird typo or expectation of how something should work. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
Hi Dan, On May 7, 2007, at 10:06 PM, Jean-François Mertens wrote: On 08 May 2007, at 04:53, Daniel Macks wrote: On Mon, May 07, 2007 at 05:51:04PM -0500, Remi Mommsen wrote: I guess it wouldn't be too difficult to extend the variant syntax to the Shlibs field. Is there any show-stopper/stumbling block which I'm not aware of? Nope, just need to make sure that validator also enforces a BuildDepends on a version of fink that knows about this new syntax. Otherwise a package built by an older version of fink will include that literal varianting syntax as part of the Shlibs field. Hoping I understand correctly: it is not only variants, but the full power of conditionals that should be available there. E.g., some pkgs name their libs in an architecture-dependent way: no reason to make any variant, but conditionals are needed.. (cf eg the the info files for pwlib1 or openh323-1) Thanks for implementing this feature. I gave it a try and it seems to mostly work. There is an issue with the validation when running with 'fink -m' when it comes to validating the deb directories: Validating .deb dir /sw/src/fink.build/root-root5-shlibs-5.14.00e-3... Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it does not exist! Removing runtime build-lock... Removing build-lock package... These shlibs do indeed not exists and are protected by the conditional. Here's a snippet of the shlibs field: (%type_pkg[-cernlib]) %p/lib/root/libEGPythia6.5.dylib 5.0.0 %n (=5.02.00-1) (%type_pkg[-geant4]) %p/lib/root/libG4root.5.dylib 5.0.0 %n (=5.14.00-1) (%type_pkg[-qt]) %p/lib/root/libGQt.5.dylib 5.0.0 %n (=5.15.04-2) %p/lib/root/libGX11.5.dylib 5.0.0 %n (=5.02.00-1) %p/lib/root/libGX11TTF.5.dylib 5.0.0 %n (=5.02.00-1) (%type_pkg[-cernlib]) %p/lib/root/libHbook.5.dylib 5.0.0 %n (=5.02.00-1) %p/lib/root/libHist.5.dylib 5.0.0 %n (=5.02.00-1) Interesting to note is that the validation does not complain about the libraries which are only built by the '-qt' variant (and which are missing, too). I guess, that is connected to the order of the type field: Type: -cernlib (boolean), -geant4 (boolean), -qt (boolean) i.e. it looks like that only the last conditional is taken into account. I copied the current version of the root5-devel info and patch file to: http://www-clued0.fnal.gov/~mommsen/fink/ Remi -- Computers are like air-conditioners, they stop working properly when you open Windows. (Anonymous) * Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of Manchester URL:http://cern.ch/mommsen Fermilab, MS 357 voice:++1 (630) 840-8321 P.O. Box 500 fax:++1 (630) 840-2649 Batavia, Il 60510, US home:++1 (630) 236-0932 * - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
On Sun, May 06, 2007 at 08:39:53PM -0700, David R. Morrison wrote: On May 6, 2007, at 9:09 AM, Remi Mommsen wrote: I have a package (root5) which builds many shlibs and has different variants. Depending on the variant, some shlibs are built or not [...] How do I handle this situation? I haven't looked at the package to see what your variant structure is, but presumably there is some core collection of dylib files which are built for all variants, and then some extra ones which only occur in some variants? A further question is whether the dylib that are exist in all are *the same* in all. That's important for drm's Idea #2: 2) A basic package would provide the dylibs that are in common for all variants, and then the variant packages would build other splitoffs with other dylibs in them (as needed). The disadvantage of this is that people may have to compile things twice. You would probably also need separate .info files. If a dylib file that exists in multiple variants is not the same in all of them, then a core package plus varianted add-ons won't work. OTOH, if the core dylib are identical in all variants, then one probably could hack the build to avoid building those core again in the variant add-on packages. Quick example would be the python bindings for gnome-menus: the shared libraries and python bindings are all part of the same source tarball and is designed so a single ./configure make builds it all, so we first build the libs with python disabled, and then, in a separate package, build *just* the python bindings for a given python variant by hacking to point to the installed lib instead of the one in the build dir. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
Hi Dan, On May 7, 2007, at 2:43 AM, Daniel Macks wrote: On Sun, May 06, 2007 at 08:39:53PM -0700, David R. Morrison wrote: On May 6, 2007, at 9:09 AM, Remi Mommsen wrote: I have a package (root5) which builds many shlibs and has different variants. Depending on the variant, some shlibs are built or not [...] How do I handle this situation? I haven't looked at the package to see what your variant structure is, but presumably there is some core collection of dylib files which are built for all variants, and then some extra ones which only occur in some variants? A further question is whether the dylib that are exist in all are *the same* in all. AFAIK, the dylib are the same. However, there are configuration files mapping the dependencies btw libraries for the run-time C++ interpreter. These files only contain the libraries which are actually built. Thus, one would need to hack these configuration files depending on the add-on packages. That's important for drm's Idea #2: 2) A basic package would provide the dylibs that are in common for all variants, and then the variant packages would build other splitoffs with other dylibs in them (as needed). The disadvantage of this is that people may have to compile things twice. You would probably also need separate .info files. If a dylib file that exists in multiple variants is not the same in all of them, then a core package plus varianted add-ons won't work. OTOH, if the core dylib are identical in all variants, then one probably could hack the build to avoid building those core again in the variant add-on packages. Quick example would be the python bindings for gnome-menus: the shared libraries and python bindings are all part of the same source tarball and is designed so a single ./configure make builds it all, so we first build the libs with python disabled, and then, in a separate package, build *just* the python bindings for a given python variant by hacking to point to the installed lib instead of the one in the build dir. I guess this would be possible with a lot of hacking and testing (possibly repeating each time when a new version is released). In addition, I would need to maintain 8 different info files instead of one. I hope we can find a better solution as this solution is (too) time consuming IMHO. Remi -- Computers are like air-conditioners, they stop working properly when you open Windows. (Anonymous) * Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of Manchester URL:http://cern.ch/mommsen Fermilab, MS 357 voice:++1 (630) 840-8321 P.O. Box 500 fax:++1 (630) 840-2649 Batavia, Il 60510, US home:++1 (630) 236-0932 * - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remi Mommsen wrote: I guess this would be possible with a lot of hacking and testing (possibly repeating each time when a new version is released). In addition, I would need to maintain 8 different info files instead of one. I hope we can find a better solution as this solution is (too) time consuming IMHO. I think it makes more sense to have variants in shlibs in some form, it will take some time to do right though. In the meantime, it's safe to ignore those specific errors in validation for the sake of getting the package out, I think, but ultimately we need a way to: a) ignore private shared libs that have no public API/headers b) handle differences in builds with virtual packages -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGP5N7Uu+jZtP2Zf4RArNtAJ9c9nnmpBzl1zRcgCVt2NPg3jsoTACfbmTY fDHeHiUZStXB/EmUA4xGQzM= =Ik3Y -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
Benjamin Reed wrote: [] a) ignore private shared libs that have no public API/headers In the case of root5, aren't all dylibs private, or is there another package depending on one of them? I would just scrap the whole shlibs splitoff stuff for this package. It isn't worth the hassle. -- Martin - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
On Mon, May 07, 2007 at 05:51:04PM -0500, Remi Mommsen wrote: Hi Martin, On May 7, 2007, at 5:13 PM, Martin Costabel wrote: Benjamin Reed wrote: [] a) ignore private shared libs that have no public API/headers In the case of root5, aren't all dylibs private, or is there another package depending on one of them? I would just scrap the whole shlibs splitoff stuff for this package. It isn't worth the hassle. There is no (official) fink package depending on it. Most high energy physics experiments (and others) using root to build their specific applications against it. Thus it could be that somewhere somebody relies on the fact that shlibs of older root version can be kept in parallel to newer ones. I'm not aware of anybody who started packaging the experiment specific code into fink package(s), thought. I guess it wouldn't be too difficult to extend the variant syntax to the Shlibs field. Is there any show-stopper/stumbling block which I'm not aware of? Nope, just need to make sure that validator also enforces a BuildDepends on a version of fink that knows about this new syntax. Otherwise a package built by an older version of fink will include that literal varianting syntax as part of the Shlibs field. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
On 08 May 2007, at 04:53, Daniel Macks wrote: On Mon, May 07, 2007 at 05:51:04PM -0500, Remi Mommsen wrote: I guess it wouldn't be too difficult to extend the variant syntax to the Shlibs field. Is there any show-stopper/stumbling block which I'm not aware of? Nope, just need to make sure that validator also enforces a BuildDepends on a version of fink that knows about this new syntax. Otherwise a package built by an older version of fink will include that literal varianting syntax as part of the Shlibs field. Hoping I understand correctly: it is not only variants, but the full power of conditionals that should be available there. E.g., some pkgs name their libs in an architecture-dependent way: no reason to make any variant, but conditionals are needed.. (cf eg the the info files for pwlib1 or openh323-1) Jean-Francois - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Shlibs field and variants
Hi, I have a package (root5) which builds many shlibs and has different variants. Depending on the variant, some shlibs are built or not. So far, I just listed all possibly built libraries in the Shlibs field. The latest (cvs head) version of fink complains now about the missing libraries listed in the shlibs field: Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it does not exist! How do I handle this situation? TIA, Remi -- If it's green, it's biology. If it stinks, it's chemistry. If it has numbers, it's math. If it doesn't work, it's technology. (anonymous) * Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of Manchester URL:http://cern.ch/mommsen Fermilab, MS 357 voice:++1 (630) 840-8321 P.O. Box 500 fax:++1 (630) 840-2649 Batavia, Il 60510, US home:++1 (630) 236-0932 * - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
On May 6, 2007, at 9:09 AM, Remi Mommsen wrote: Hi, I have a package (root5) which builds many shlibs and has different variants. Depending on the variant, some shlibs are built or not. So far, I just listed all possibly built libraries in the Shlibs field. The latest (cvs head) version of fink complains now about the missing libraries listed in the shlibs field: Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it does not exist! How do I handle this situation? TIA, Remi Hi Remi. The basic problem here is that we want a reliable mapping between install-name and compatibility version of a dynamic library and what fink package installs it. I haven't looked at the package to see what your variant structure is, but presumably there is some core collection of dylib files which are built for all variants, and then some extra ones which only occur in some variants? I see two possible strategies for handling this, but I'm willing to be convinced that there are others I haven't thought of. 1) The contents of your Shlibs field has to depend on the variant. This is unpleasant, because we hadn't anticipated it and fink's variant code can't handle this smoothly. It would require separate .info files for the various variants. (It also has the unfortunate property that there are several different packages which could be used to provide a given dylib, so these should all conflict/ replace each other, which gets messy where shared library packages are involved.) 2) A basic package would provide the dylibs that are in common for all variants, and then the variant packages would build other splitoffs with other dylibs in them (as needed). The disadvantage of this is that people may have to compile things twice. You would probably also need separate .info files. Can anybody think of another strategy? -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field and variants
Hi David, On May 6, 2007, at 10:39 PM, David R. Morrison wrote: On May 6, 2007, at 9:09 AM, Remi Mommsen wrote: Hi, I have a package (root5) which builds many shlibs and has different variants. Depending on the variant, some shlibs are built or not. So far, I just listed all possibly built libraries in the Shlibs field. The latest (cvs head) version of fink complains now about the missing libraries listed in the shlibs field: Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it does not exist! Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it does not exist! How do I handle this situation? TIA, Remi Hi Remi. The basic problem here is that we want a reliable mapping between install-name and compatibility version of a dynamic library and what fink package installs it. I haven't looked at the package to see what your variant structure is, but presumably there is some core collection of dylib files which are built for all variants, and then some extra ones which only occur in some variants? Correct. I see two possible strategies for handling this, but I'm willing to be convinced that there are others I haven't thought of. 1) The contents of your Shlibs field has to depend on the variant. This is unpleasant, because we hadn't anticipated it and fink's variant code can't handle this smoothly. It would require separate .info files for the various variants. (It also has the unfortunate property that there are several different packages which could be used to provide a given dylib, so these should all conflict/replace each other, which gets messy where shared library packages are involved.) 2) A basic package would provide the dylibs that are in common for all variants, and then the variant packages would build other splitoffs with other dylibs in them (as needed). The disadvantage of this is that people may have to compile things twice. You would probably also need separate .info files. Having separate info files would be quite messy. Currently, there are 8 combinations built from one info file. I don't want to build all extensions by default (and split them into split-offs) as these extensions pull in other huge packages which only a few people actually need. Can anybody think of another strategy? Would it be possible to extend the variant syntax to allow it also in the shlibs field, i.e. one could put something like Shlibs: %p/lib/root/libRooFit.5.dylib5.0.0 %n (=5.02.00-1) (%type_pkg[-qt]) %p/lib/root/libQtRoot.5.dylib5.0.0 %n (=5.15.04-2) where the first library is available in all variants, and the second only in the '-qt' variants? Remi -- … there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. Donald Rumsfeld * Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of Manchester URL:http://cern.ch/mommsen Fermilab, MS 357 voice:++1 (630) 840-8321 P.O. Box 500 fax:++1 (630) 840-2649 Batavia, Il 60510, US home:++1 (630) 236-0932 * - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Shlibs field for ode package
Are there any experts out there on the Shlibs field? I'm trying to submit a .info for a package called ODE, but I'm not sure how to get the Shlibs field just right. Any assistance would be appreciated. The tracker item is here: https://sourceforge.net/tracker/index.php? func=detailaid=1563896group_id=17203atid=414256 Thanks, Trevor smime.p7s Description: S/MIME cryptographic signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field for ode package
On Sep 25, 2006, at 5:31 AM, Trevor Harmon wrote: Are there any experts out there on the Shlibs field? I'm trying to submit a .info for a package called ODE, but I'm not sure how to get the Shlibs field just right. Any assistance would be appreciated. The tracker item is here: https://sourceforge.net/tracker/index.php? func=detailaid=1563896group_id=17203atid=414256 Hi, I can't believe someone put this crap into a Makefile.am: # Fake an executable in order to get a shared library # Note the elegant and cunning way to trick Autotools to install a program # in a lib directory. --Rodrigo traplibdir=$(prefix)/lib [EMAIL PROTECTED]@ traplib_PROGRAMS=libode libode_SOURCES= libode_DEPENDENCIES = libfast.a libode.a libode_LDFLAGS= @SHARED_LDFLAGS@ if USE_SONAME libode_LDFLAGS+=-Wl,-soname,@ODE_SONAME@ endif libode_LDADD=$(libode_a_OBJECTS) $(libfast_a_OBJECTS) if OPCODE libode_DEPENDENCIES+= libOPCODE.a libode_LDADD+=$(libOPCODE_a_OBJECTS) endif Please shoot upstream and tell them to use GNU libtool. He obviously thinks he's smartly outwitting the autotools, but with crap like this there is little or no point to him using the autotools in the first place. In the meantime, you will have to modify the build so that it builds a proper versioned shared library. e.g. libode.0.dylib. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Shlibs field for ode package
On Sep 25, 2006, at 7:49 AM, Peter O'Gorman wrote: In the meantime, you will have to modify the build so that it builds a proper versioned shared library. e.g. libode.0.dylib. Short term fix might be to edit configure and set the so_ext to . 0.dylib, also changing SHARED_LDFLAGS to -dynamiclib -install_name $libdir/libodt.0.dylib you will have to create the libodt.dylib symlink in the -dev splitoff manually. You should still shoot upstream however, using GNU libtool would gain portability to most other unix. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Shlibs field
On May 15, 2004, at 11:12 AM, Spundun Bhatt wrote: - Shlibs: %p/lib/libgsf-1.1.dylib 10.2.0 %n (= 1.8.2-1) + Shlibs: %p/lib/libgsf-1.1.dylib 10.2.0 %n (= 1.9.0-1) To reiterate for everyone, this is wrong. See http://fink.sourceforge.net/doc/packaging/policy.php? phpLang=en#sharedlibs under 'the shlibs field. Also http://www.mail-archive.com/[EMAIL PROTECTED]/ msg05032.html -Ben --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
