I have a version of the Gimp with multithreading enabled compiling. I am
now working on Perl-Fu support.
It seems to want libgimp already installed in /sw/lib. Is there any
preferred/clean way to do this?
Alexander Strange
[EMAIL PROTECTED]
"Gandalf, has your fondness for the hobbits' weed af
At 20:45 Uhr -0500 02.02.2002, Kyle Moffett wrote:
> On Saturday, February 2, 2002, at 08:25 , Randal L. Schwartz wrote:
>
>>Kyle> $hash->{variant}{xwin} = the contents of the variant foo
>>Kyle> $hash->{variant}{xwin}{cppflags} = the CPPFlags used when compiling
>>Kyle> with xwindows support
>>
On Saturday, February 2, 2002, at 08:25 , Randal L. Schwartz wrote:
Kyle> $hash->{variant}{xwin} = the contents of the variant foo
Kyle> $hash->{variant}{xwin}{cppflags} = the CPPFlags used when compiling
Kyle> with xwindows support
I hope you realize you can't use both of these at the same time
> "Kyle" == Kyle Moffett <[EMAIL PROTECTED]> writes:
Kyle> $hash->{variant}{xwin} = the contents of the variant foo
Kyle> $hash->{variant}{xwin}{cppflags} = the CPPFlags used when compiling
Kyle> with xwindows support
I hope you realize you can't use both of these at the same time.
If $hash-
Just pursing this thought a bit further: The rule would be, if package foo
is of Type: shlibs, then no package is allowed to Depends: foo. It may
only Depends: foo-shlibs, and BuildDepends: foo.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Maybe this will be clearer if we declare "Type: shlibs" for these packages.
As you've pointed out, Max, this is really a different kind of thing
than the other versioning we've been discussing, and flagging it that
way will help people to remember this.
My examples libpng-1.0.12-3 and libpng-shli
On Saturday, February 2, 2002, at 05:11 , Max Horn wrote:
At 16:50 Uhr -0500 02.02.2002, Kyle Moffett wrote:
I would like to propose a format for XML info documents for Fink.
[snip]
Actually, in my mind, there is no difference at all - even the "final" format would be parsed into the same hash f
At 18:41 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Another crucial thing, to get the upgrade to work:
>
>foo-shlibs version a.b-c has to "Replace: foo (< a.b-c)".
>
>The reason for this is, if you have the OLD foo package installed, dpkg
>is going to try to install foo-shlibs before install
At 18:29 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Max Horn <[EMAIL PROTECTED]> wrote:
[...]
> > >The WHOOPS above is this: the value of %n is foo, not foo-shlibs. So I
>> >think that we are creating %i/share/doc/%n not %i/share/doc/%n-shlibs.
>> >Either that, or we have to duplicate t
Another crucial thing, to get the upgrade to work:
foo-shlibs version a.b-c has to "Replace: foo (< a.b-c)".
The reason for this is, if you have the OLD foo package installed, dpkg
is going to try to install foo-shlibs before installing the new foo...
But there are files which conflict between
Max Horn <[EMAIL PROTECTED]> wrote:
> At 18:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
[snip]
>
> >There is one other issue: sometimes, there are a bunch of auxiliary
> >files which belong to a particular version of the library, and which
> >could get stored in /sw/lib/foo/N/ or in /sw/s
Gnumeric crashes for me upong launch. never has been different. But
now also gabber crashes for me when I try to login. Looking at my
stack trace, both crash inside some gtkmm/gnomemm function... I
wonder if there is something deeper going on there...
In any case, I am using new updated gnome
At 18:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
>H... I'm confused about the dependency relationships between foo-shlibs
>and foo (using your terminology, Max).
>
>Do we say that foo depends on foo-shlibs? I guess that is OK; foo-shlibs
>is going to have to load the entire source to g
At 17:36 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Two more comments about the new zlib
>
>1) I have only a vague recollection about the earlier discussion of this.
>Was zlib originally absent from darwin/OS X, and added in a later revision?
>If so, do you need some kind of darwin-version te
At 17:41 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Max Horn <[EMAIL PROTECTED]> wrote:
>
>> I have to correct myself: the actual cause is that we use a different
>> install_name at link time, i.e. we give libz.1.dylib as install_name,
>> and Apple obviously libz.1.1.3.dylib.
>
>Very good.
H... I'm confused about the dependency relationships between foo-shlibs
and foo (using your terminology, Max).
Do we say that foo depends on foo-shlibs? I guess that is OK; foo-shlibs
is going to have to load the entire source to get built, anyway, so there
is no point in have it BuildDepend
At 17:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Hi again Max.
>
>I was looking more closely at a shared library example in Debian, and it
>appears that they use a similar trick to what you've just done with zlib:
>they divide the files between the packages like this:
>
>Package foo contai
Max Horn <[EMAIL PROTECTED]> wrote:
> I have to correct myself: the actual cause is that we use a different
> install_name at link time, i.e. we give libz.1.dylib as install_name,
> and Apple obviously libz.1.1.3.dylib.
Very good. So the strategy I am proposing in my shared libraries messages
Two more comments about the new zlib
1) I have only a vague recollection about the earlier discussion of this.
Was zlib originally absent from darwin/OS X, and added in a later revision?
If so, do you need some kind of darwin-version test for the new package?
2) Since Apple is providing libz.h,
At 22:59 Uhr +0100 02.02.2002, Max Horn wrote:
>>Here is my question, though. Do you know why the library got listed as
>>libz.1.dylib before, but now it is getting listed at libz.1.1.3.dylib?
>>It seems to me that it is more robust, for possible future upgrades,
>>if the otool listing gives libf
At 16:50 Uhr -0500 02.02.2002, Kyle Moffett wrote:
>I would like to propose a format for XML info documents for Fink.
>Please note that this is very preliminary and subject to much
>change, especially since the reason I'm putting this up here is so
>that it can get changed, edited, customized,
Hi again Max.
I was looking more closely at a shared library example in Debian, and it
appears that they use a similar trick to what you've just done with zlib:
they divide the files between the packages like this:
Package foo contains:
/sw/lib/foo.N.x.y.dylib
/sw/lib/foo.N.dylib -> /sw/lib/
At 16:08 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Hi Max. I'm testing your new zlib, and it works great. In both of the
>packages I depended which depend on zlib, at the outset, otool -L gave
> /sw/lib/libz.1.dylib (compat. 1.1.3, current 1.1.3)
>
>Then I installed the new zlib and ever
I would like to propose a format for XML info documents for Fink.
Please note that this is very preliminary and subject to much change,
especially since the reason I'm putting this up here is so that it can
get changed, edited, customized, and finalized. Once this is finalized,
and even befo
Hi Max. I'm testing your new zlib, and it works great. In both of the
packages I depended which depend on zlib, at the outset, otool -L gave
/sw/lib/libz.1.dylib (compat. 1.1.3, current 1.1.3)
Then I installed the new zlib and everything still ran.
Then I recompiled my packages; now otill -L
At 22:03 Uhr -0500 01.02.2002, Bill Bumgarner wrote:
[...]
>
>Version of libtool?
>
>I'm not at all sure; how do I tell?
By looking at ltmain.sh
> In any case, swapping in the ltmain.
>sh and ltconfig from Fink didn't help; I still saw the version
>mismatch problem.
What do you mean, "sti
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
>
>***
>
27 matches
Mail list logo
