On Mon, 20 Sep 2010 23:23:50 -0400, Daniel Macks wrote:
On Tue, 21 Sep 2010 06:26:48 0900, "David R. Morrison" wrote:
> >
> > Also, I'm wondering if we should maybe enhance that validator test
> so that if it finds a Shlibs with an incomplete pathname, it gives
> additional advice (suc
On Sep 22, 2010, at 1:28 PM, Benjamin Reed wrote:
> %i would be wrong, you tell cmake the *real* install prefix, and
> then use DESTDIR to set it to the temporary root (%d). Otherwise,
> %i is the build directory: /sw/src/fink.build/package/foo/sw and
> then DESTDIR=%p makes it put another
On 9/22/10 10:06 AM, Ebrahim Mayat wrote:
> To recap the build and install scripts and the SplitOff field are:
>
> CompileScript:<<
>#!/bin/sh -ev
>/bin/mkdir build
>cd build
>%p/bin/cmake \
>-DCMAKE_INSTALL_PREFIX=%i \
>..
> <<
> InstallScript:<<
>#!/bin/sh -ev
>c
On Sep 20, 2010, at 5:12 PM, Benjamin Reed wrote:
> This is a common issue with cmake projects. People write the cmake
> bits on linux and don't realize they're missing settings for proper
> ld initialization on other platforms. :)
>
>
> You generally need something along the lines of this
On Tue, 21 Sep 2010 06:26:48 0900, "David R. Morrison" wrote:
>
> Also, I'm wondering if we should maybe enhance that validator test
so that if it finds a Shlibs with an incomplete pathname, it gives
additional advice (such as what Ben wrote in this email...)
I think the actual bug is"non-a
On Sep 20, 2010, at 5:12 PM, Benjamin Reed wrote:
> On 9/20/10 5:03 PM, Ebrahim Mayat wrote:
>> Since we are in the process of migrating to cmake from autotools, i
>> would like to rectify this error.
>
> This is a common issue with cmake projects. People write the cmake
> bits on linux and
This sounds like something which should be added to the FAQ if its not there
already.
Also, I'm wondering if we should maybe enhance that validator test so that if
it finds a Shlibs with an incomplete pathname, it gives additional advice (such
as what Ben wrote in this email...)
-- Dave
On
On 9/20/10 5:03 PM, Ebrahim Mayat wrote:
> Since we are in the process of migrating to cmake from autotools, i
> would like to rectify this error.
This is a common issue with cmake projects. People write the cmake bits
on linux and don't realize they're missing settings for proper ld
initial
On Sep 20, 2010, at 11:15 AM, Alexander Hansen wrote:
$ otool -L /sw/src/fink.build/root-fluidsynth-shlibs-1.1.2-358/sw/
lib/libfluidsynth.1.dylib
/sw/src/fink.build/root-fluidsynth-shlibs-1.1.2-358/sw/lib/
libfluidsynth.1.dylib:
libfluidsynth.1.dylib (compatibility version 1.0.0, curre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/20/10 10:15 AM, Ebrahim Mayat wrote:
> Good Day
>
> When preparing a package update I get the following error:
>
>> Validating .deb dir /sw/src/fink.build/root-fluidsynth-1.1.2-358...
>> Package looks good!
>> dpkg-deb -b root-fluidsynth-1.1.2-3
Good Day
When preparing a package update I get the following error:
> Validating .deb dir /sw/src/fink.build/root-fluidsynth-1.1.2-358...
> Package looks good!
> dpkg-deb -b root-fluidsynth-1.1.2-358 /sw/fink/10.5/local/main/
> binary-darwin-powerpc
> dpkg-deb: building package `fluidsynth' in `
On Jan 24, 2009, at 10:15 PM, Daniel Johnson wrote:
> libode.dylib needs to go in the dev package, not shlibs. It appears
> that nothing currently depends on ode, yes? If so, I'd suggest
> removing the ode-dev splitoff entirely, leaving all the dev files in
> the main ode package. Make it Bu
On Jan 24, 2009, at 7:33 PM, Trevor Harmon wrote:
> On Jan 24, 2009, at 5:54 PM, Daniel Johnson wrote:
>
>> There are a couple of problems here. You have too many packages.
>> There only needs to be a -dev and a -shlibs package. The
>> unnecessary ode package only contains 2 files: libode.1.0
On Jan 24, 2009, at 5:54 PM, Daniel Johnson wrote:
There are a couple of problems here. You have too many packages.
There only needs to be a -dev and a -shlibs package. The unnecessary
ode package only contains 2 files: libode.1.0.0.dylib, which needs
to be in ode-shlibs and libode.la, whic
On Jan 24, 2009, at 5:33 PM, Daniel Macks wrote:
> The validator messages and otool-L are all self-consistent: the
> problem (and it *is* a problem) is that the lib is coded as if it
> exists in /opt/ode instead of in %p.
Actually, the reason why otool reports /opt/ode is most likely because
I
On Jan 24, 2009, at 4:29 PM, Trevor Harmon wrote:
> Hi,
>
> I'm the maintainer of the ode package, which has had a history of
> problems related to shlibs [1]. Luckily, ode now uses libtool, and
> it also fixes a problem that was preventing successful builds on
> Leopard, so I thought I'd h
On Sat, Jan 24, 2009 at 04:29:23PM -0500, Trevor Harmon wrote:
> Hi,
>
> I'm the maintainer of the ode package, which has had a history of
> problems related to shlibs [1]. Luckily, ode now uses libtool, and it
> also fixes a problem that was preventing successful builds on Leopard,
> so I t
Hi,
I'm the maintainer of the ode package, which has had a history of
problems related to shlibs [1]. Luckily, ode now uses libtool, and it
also fixes a problem that was preventing successful builds on Leopard,
so I thought I'd hit two birds with one stone and upgrade Fink's
package for o
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
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 /
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-s
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 ma
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 t
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
> wh
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.
--
Ma
-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 ca
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
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 situat
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
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) versi
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
Fink's Shlibs policy has been updated to handle 64bit libraries and
'fat' libraries.
Effective immediately, any fink package which installs shared 64bit
or 'fat' libraries should use a modified form of the Shlibs field in
which either "64" or "32-64", as appropriate, has been appended to
t
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 "-dy
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:
>
> h
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=detail&aid=156
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D. HÃhn wrote:
| I maintain the current gsasl which is at compat 7.0.0 and 7.0.0 for the
| other number.
I think you mean that the current version is 7.0.0 and the compatibility
version is 7.0.0 also. Okay.
|
| The current version is old and needs updat
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hello folks.
I will be the frist to agree that the shlibs thingie still make me tear
my hair out.
I maintain the current gsasl which is at compat 7.0.0 and 7.0.0 for the
other number.
The current version is old and needs updating :) so there is 0.2
Daniel,
The situation with fftw is as follows. The gromacs md-simulation
package, which is just entering fink unstable, can be used with
LAM-MPI to run more effectively on multiple nodes and processors.
This is done by having lammpi installed and using the --enable-mpi
configure option. The gro
On Thu, Aug 12, 2004 at 12:57:43AM -0400, Jack Howarth wrote:
> I am trying to create a -mpi variant of the fftw package using the
> Type field. I have managed to create a fftw.info that will build either
> fftw/fftw-shlibs or fftw-mpi/fftw-mpi-shlibs depending on what (fftw
> or fftw-mpi) is p
I am trying to create a -mpi variant of the fftw package using the
Type field. I have managed to create a fftw.info that will build either
fftw/fftw-shlibs or fftw-mpi/fftw-mpi-shlibs depending on what (fftw
or fftw-mpi) is passed to 'fink install'. However am baffled on what
options I have to
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#sharedl
On Thu, 2002-10-10 at 15:45, David R. Morrison wrote:
> I'm working on the next phase of the shlibs project, and I'd like to get the
> opinion of other Fink developers on one aspect of this.
>
> The system will automatically examine the libraries which have been linked
> to by a particular binary
I'm working on the next phase of the shlibs project, and I'd like to get the
opinion of other Fink developers on one aspect of this.
The system will automatically examine the libraries which have been linked
to by a particular binary, and keep track of which packages provide those
libraries. The
On Saturday, May 4, 2002, at 11:11 AM, David R. Morrison wrote:
> Here are my thoughts (on the original message and Max's followup):
>
> How hard would it be to modify things so that everything was installed
> into
> libs/kde-2.0/
> rather than libs/ ? (I chose a random version number, of co
Here are my thoughts (on the original message and Max's followup):
How hard would it be to modify things so that everything was installed into
libs/kde-2.0/
rather than libs/ ? (I chose a random version number, of course you should
use the actual one.) If this can be done without too much tro
At 10:42 Uhr -0400 04.05.2002, Benjamin Reed wrote:
>In continuing to work on KDE, we've run into a couple of interesting
>problems with the -shlibs splitoff. KDE uses libltdl heavily for
>dlopening libraries on the fly, and uses the .la's to determine the
>names of those libraries.
>
>Things
In continuing to work on KDE, we've run into a couple of interesting
problems with the -shlibs splitoff. KDE uses libltdl heavily for
dlopening libraries on the fly, and uses the .la's to determine the
names of those libraries.
Things will not even start without the .la's, so this will be an
I fully agree with this, it hurts on one to have them but helps us
developpers in the mean time.
[EMAIL PROTECTED] writes:
>Someday, later, we will want to introduce Shlibs and start to use it.
>If we are sure that this will be the name of the field, it would be nice
>to have "fink validate" not
Max Horn <[EMAIL PROTECTED]> wrote:
> >The reason for bringing this up now is it would be good to start encouraging
> >people to provide this information in their packages, pretty soon. To
> >avoid "fink validate" problems, we might want to add one more field (Shlibs)
> >to the list of known fie
At 10:47 Uhr -0500 17.03.2002, David R. Morrison wrote:
>If I understand correctly what the dpkg shlibs stuff will eventually do
>for us, at some point in the future each fink package which provides
>shared libraries will need to give some data about those libraries to
>be used by the dpkg-shlibs
If I understand correctly what the dpkg shlibs stuff will eventually do
for us, at some point in the future each fink package which provides
shared libraries will need to give some data about those libraries to
be used by the dpkg-shlibs system.
Max, will we put this directly in the .info file, d
At 19:26 Uhr -0500 01.02.2002, David R. Morrison wrote:
>Yes, the installation order business bothered me. One possibility is
>to force people to install in the correct order, by this trick:
>
>Package: db1
>
>***
>
>Package: db2
>Replaces: db1
>
>***
>
>Package: db3
>Replaces: db1, db2
>
>***
>
On Friday, February 1, 2002, at 07:19 , Max Horn wrote:
> That sums it up pretty well, indeed.
>
> The only potentially trouble spot is that the order in which (in your
> example) db3 and db4 are installed affects to which the db.dylib
> symlink points. If a package has to link against a partic
Yes, the installation order business bothered me. One possibility is
to force people to install in the correct order, by this trick:
Package: db1
***
Package: db2
Replaces: db1
***
Package: db3
Replaces: db1, db2
***
This way, if you try to install db2 after db3, you will be told that you
That sums it up pretty well, indeed.
The only potentially trouble spot is that the order in which (in your
example) db3 and db4 are installed affects to which the db.dylib
symlink points. If a package has to link against a particular
version, that could generate problems. Alas, in such cases,
I've been studying the Debian policy about shared libraries, and I think
I understand their strategy much better now.
It has several components. First, the libraries themselves are separated
from the headers -- you have to have two packages per program. (Well,
actually three in many cases, beca
At 17:31 Uhr -0600 01.02.2002, Ken Williams wrote:
>On Thursday, January 31, 2002, at 11:28 AM, Max Horn wrote:
>>Achieving that is a quite involved task indeed, since it means you
>>have to keep parts of a package around (like libtiff.3.dylib), enve
>>though the rest of the package is removed,
On Thursday, January 31, 2002, at 11:28 AM, Max Horn wrote:
> Achieving that is a quite involved task indeed, since it means you have
> to keep parts of a package around (like libtiff.3.dylib), enve though
> the rest of the package is removed, creating "orphaned" files that
> nobody owns anymo
On Thursday, January 31, 2002, at 05:28 , Max Horn wrote:
> Of course that is suboptimal. In this situation, the only way for the
> user to update would be to first remove the old versions of the
> dependant stuff, then update the lib, then reinstall the removed stuff.
> Yucky.
Yes, I agree.
At 13:58 Uhr -0500 31.01.2002, David R. Morrison wrote:
>Thanks for the explanation, Max. It's something that I kinda knew, but
>had forgotten.
>
>I haven't ever used Debian/Linux, but what I am hoping will happen after
>we get this going is this: if I install a new version of a library,
>dpkg w
Thanks for the explanation, Max. It's something that I kinda knew, but
had forgotten.
I haven't ever used Debian/Linux, but what I am hoping will happen after
we get this going is this: if I install a new version of a library,
dpkg will automatically recompile all of the guys that depend on it.
At 11:37 Uhr -0500 30.01.2002, David R. Morrison wrote:
>I'll take over as the new libpng maintainer (from chrisp). I made a fink
>package for the latest upstream version. However, I have not put it on
>CVS, because the major version number has changed and if you install the
>new one, you will b
62 matches
Mail list logo
