On 03 Dec 2007, at 07:02, Peter O'Gorman wrote:
> Jean-François Mertens wrote:
>>>
>> On 03 Dec 2007, at 05:35, Peter O'Gorman wrote:
>>
>>>
>>> Did you check with otool -L that libeplplot loads libX11?
>>
>> But I see that Peter will give you a quicker fix - at least for
>> this specific problem
On Mon, Dec 03, 2007 at 12:58:18AM -0500, Daniel Macks wrote:
> Hooray for upstream bugs!
>
> All of the shared libraried in emboss-5.0.0-3 are deficient in their
> linkages. They don't link any other libraries, yet they all use
> symbols from other libraries. See attached file for output from the
Hooray for upstream bugs!
All of the shared libraried in emboss-5.0.0-3 are deficient in their
linkages. They don't link any other libraries, yet they all use
symbols from other libraries. See attached file for output from the
"fink-dyld-link-test" thing in my experimental/ directory on cvs.sf to
On 03 Dec 2007, at 05:59, Koen van der Drift wrote:
>
> On Dec 2, 2007, at 11:49 PM, Jean-François Mertens wrote:
>
>> But I see that Peter will give you a quicker fix - at least for
>> this specific problem - the principle is the same, and if
>> you want to be thorough you go through the check I
>
On 03 Dec 2007, at 05:35, Peter O'Gorman wrote:
>
> Did you check with otool -L that libeplplot loads libX11?
But I see that Peter will give you a quicker fix - at least for
this specific problem - the principle is the same, and if
you want to be thorough you go through the check I
suggested _
On Dec 2, 2007, at 11:35 PM, Peter O'Gorman wrote:
>>
>>
>> However, now I get the following, again similar error:
>>
>> t/1Can't load '/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-
>> Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle' for module
>> Bio::Emboss: dlopen(/sw/src/fink.
On 03 Dec 2007, at 05:03, Daniel Macks wrote:
> Yup. Often (but sporadically) over past week or two. Certainly a
> problem on SF's server end, not ours. Please file a bug with
> SourceForge.
Done.
http://sourceforge.net/tracker/index.php?
func=detail&aid=1843109&group_id=1&atid=21
JF
---
Koen van der Drift wrote:
> On Dec 2, 2007, at 10:55 AM, Koen van der Drift wrote:
>> But, I now get another similar error:
>>
>> t/1Can't load '/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-
>> Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle' for module
>> Bio::Emboss: dlopen(/s
On Mon, Dec 03, 2007 at 03:55:12AM +0100, Jean-Fran?ois Mertens wrote:
> I get since some time regularly failures of fink selfupdate
> with msgs like
> cvs update: cannot open directory /cvsroot/fink/dists/10.4/unstable/
> crypto/finkinfo: Cannot allocate memory
>
> I get those as well when using
On Dec 2, 2007, at 10:14 PM, Jean-François Mertens wrote:
>
> On 03 Dec 2007, at 04:03, Alexander Hansen wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jean-François Mertens wrote:
>>> I get since some time regularly failures of fink selfupdate with
>>> msgs like cvs update: c
On 03 Dec 2007, at 04:03, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jean-François Mertens wrote:
>> I get since some time regularly failures of fink selfupdate with
>> msgs like cvs update: cannot open directory
>> /cvsroot/fink/dists/10.4/unstable/ crypto/fink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jean-François Mertens wrote:
> I get since some time regularly failures of fink selfupdate with
> msgs like cvs update: cannot open directory
> /cvsroot/fink/dists/10.4/unstable/ crypto/finkinfo: Cannot allocate
> memory
>
> I get those as well when us
I get since some time regularly failures of fink selfupdate
with msgs like
cvs update: cannot open directory /cvsroot/fink/dists/10.4/unstable/
crypto/finkinfo: Cannot allocate memory
I get those as well when using explicitly /usr/bin/cvs, so it is not
due to fink's cvs pkg.
This happens even w
On Dec 2, 2007, at 10:55 AM, Koen van der Drift wrote:
>
> On Dec 2, 2007, at 1:07 AM, Peter O'Gorman wrote:
>
>>
>> I suggest that you find out what plsc is (rebuild the package that
>> makes
>> libajaxg.5.dylib, and grep for it) and why it is not available (what
>> provides it? grep -rl plsc
On Sat, Dec 01, 2007 at 06:20:00PM +0100, Dominique Dhumieres wrote:
> Installing oleo-1.99.16-1021 on Intel 10.5.1 failed with:
>
> ...
> checking for IceConnectionNumber in -lICE... no
> checking for Motif... libraries /sw/lib, headers in default path
> configure: error: Xbae not found; you must
Installing oleo-1.99.16-1021 on Intel 10.5.1 failed with:
...
checking for IceConnectionNumber in -lICE... no
checking for Motif... libraries /sw/lib, headers in default path
configure: error: Xbae not found; you must install it or use --without-motif
checking for Xbae... libraries test link faile
> I have made a new xmhtml.patch file that fixes this.
It does!-) Thanks for the patch.
Dominique
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Li
On Dec 2, 2007, at 1:07 AM, Peter O'Gorman wrote:
>
> I suggest that you find out what plsc is (rebuild the package that
> makes
> libajaxg.5.dylib, and grep for it) and why it is not available (what
> provides it? grep -rl plsc /sw/lib
Thanks Peter,
The grep command revealed two broken alias
The problem is purely within octave; nothing to do
with octave-forge.
Octave shows the same seg-fault on its own test-suite, cf
http://www.cae.wisc.edu/pipermail/bug-octave/2007-November/003970.html
Jean-Francois
On 01 Dec 2007, at 14:22, ALexandre Vial wrote:
> Jean-François Mertens uclouvain
19 matches
Mail list logo