Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Jean-François Mertens

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 - the principle is the same, and if
>> you want to be thorough you go through the check I
>> suggested _ it doesn't take that long ..  :)
>
> Hehe, I thought I was doing a reasonable job of giving him the  
> tools so
> that he could learn to figure stuff out by himself :-)
hoping I helped a bit too _
just thought that when the same type of problem was re-occurring with
the same pkg, it was better to give some more systematic tools..
JF
>
> Sorry, I did not see your email to Koen about this (was it off-list?).

Right _ it was _though I tried to use "Reply-to-all" throughout..
Here is what I can reconstruct
(and I see it is in my first reply that I forgot the "reply-all":

>
> On 03 Dec 2007, at 02:52, Koen van der Drift wrote:
>
>
>> 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.build/bio-emboss-pm588-5.0.0.1-1/ 
>> Bio-
>> Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 2): Symbol  
>> not
>> found: _XAllocColor
>>Referenced from: /sw/lib/EMBOSS/libeplplot.3.dylib
>>Expected in: dynamic lookup
>>   at t/1.t line 11
>> Compilation failed in require at t/1.t line 11.
>>
>> As I understand, _XAllocColor is part of libX1, and I have X11 and  
>> the
>> X11SDK installed from the Leopard DVD. I re-installed both, rebuild
>> emboss, and then tried bio-emboss-pm588 again, but still the same  
>> error.
>>
>
> Try to build your pkg (adding libs if necessary to the link  
> commands) such
> that all undefined symbols of all Mach-O files have a " (from ..."  
> in the output
> of "nm -m"
>
> Jean-Francois
>


On Dec 2, 2007, at 9:17 PM, Jean-François Mertens wrote:


> Try to build your pkg (adding libs if necessary to the link  
> commands) such
> that all undefined symbols of all Mach-O files have a " (from ..."  
> in the output
> of "nm -m"
>

Could you explain how to do that, I have no idea what you mean :-(

thanks,

- Koen.

On 03 Dec 2007, at 03:30, Koen van der Drift wrote:


>
> On Dec 2, 2007, at 9:17 PM, Jean-François Mertens wrote:
>
>
>> Try to build your pkg (adding libs if necessary to the link  
>> commands) such
>> that all undefined symbols of all Mach-O files have a " (from ..."  
>> in the output
>> of "nm -m"
>>
>
> Could you explain how to do that, I have no idea what you mean :-(
>

dpkg -S emboss | xargs file | fgrep 'Mach-O' | cut -f1 -d:
will give you the list of all binaries in your pkg

Then, for each of those in turn, say $f, run

nm -mgu $f | fgrep -v ' (from '

and you'll see all symbols for which it may be better to tell the  
linker where
to find them...

(to understand what this is doing, run first on some example just

nm -mgu $f

to see what you eliminate, and why the others are the culprits for
your problems)

Best,

Jean-Francois
__
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
> suggested _ it doesn't take that long ..  :)
>

Actually there are dozes of binaries in emboss (it's a suite of  
programs). Only three of them have the word 'emboss' in them. If I  
change the test to:

dpkg -L emboss | grep bin | xargs file | fgrep 'Mach-O' | cut -f1 -d:

I still get a long list, assuming that I didn't make an error. So it  
would take some more time to go through all of them one by one :)

thanks for all the help,

- Koen.

___
On 03 Dec 2007, at 05:37, Koen van der Drift wrote:


>
> On Dec 2, 2007, at 10:05 PM, Jean-François Mertens wrote:
>
>
>> Then, for each of those in turn, say $f, run
>>
>> nm -mgu $f | fgrep -v ' (from '
>>
>
> This line doesn't return anything. Is it complete, it looks like  
> there is something missing at the end?
>

It shouldn't return anything ! Did you try it for all binaries in the  
pkg ?

JF
_
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
>> suggested _ it doesn't take that long ..  :)
>>
>
> Actually there are dozes of binaries in emboss (it's a suite of  
> programs). Only three of them have the word 'emboss' in them. If I  
> change the test to:
>
> dpkg -L emboss | grep bin | xargs file | fgrep 'Mach-O' | cut -f1 -d:
>
> I still get a long list, assuming that I didn't make an error. So  
> it would take some m

Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Daniel Macks
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
> "fink-dyld-link-test" thing in my experimental/ directory on cvs.sf to
> see what symbols are unresolved. The makefiles all appear to know the
> libs that would be needed, but intentionally avoid dynamically linking
> them on darwin (and don't even pass the flags correctly on most other
> platforms because they didn't read the automake or libtool manual).

Attached is a patchset that fixes all these linker messes. May need to
redo the Depends/BuildDepends for the emboss.info package set after
adding this to the existing emboss.patch file.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks

diff -Nurd -x'*~' EMBOSS-5.0.0.orig/ajax/Makefile.in 
EMBOSS-5.0.0/ajax/Makefile.in
--- EMBOSS-5.0.0.orig/ajax/Makefile.in  2007-07-12 06:53:32.0 -0400
+++ EMBOSS-5.0.0/ajax/Makefile.in   2007-12-03 01:28:50.0 -0500
@@ -85,7 +85,8 @@
$(libajax_la_LDFLAGS) $(LDFLAGS) -o $@
 @[EMAIL PROTECTED] = -rpath $(libdir)
 @[EMAIL PROTECTED] = -rpath $(libdir)
-libajaxg_la_LIBADD =
+libajaxg_la_LIBADD = libajax.la ../plplot/libeplplot.la
+libajaxg_la_DEPENDENCIES = libajax.la ../plplot/libeplplot.la
 am__libajaxg_la_SOURCES_DIST = ajgraph.c ajhist.c
 @[EMAIL PROTECTED] = $(am__objects_2)
 libajaxg_la_OBJECTS = $(am_libajaxg_la_OBJECTS)
diff -Nurd -x'*~' EMBOSS-5.0.0.orig/nucleus/Makefile.in 
EMBOSS-5.0.0/nucleus/Makefile.in
--- EMBOSS-5.0.0.orig/nucleus/Makefile.in   2007-07-12 06:53:36.0 
-0400
+++ EMBOSS-5.0.0/nucleus/Makefile.in2007-12-03 01:25:23.0 -0500
@@ -55,7 +55,8 @@
 am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)"
 libLTLIBRARIES_INSTALL = $(INSTALL)
 LTLIBRARIES = $(lib_LTLIBRARIES)
-libnucleus_la_LIBADD =
+libnucleus_la_LIBADD = ../ajax/libajax.la
+libajaxg_la_DEPENDENCIES = ../ajax/libajax.la
 am__objects_1 = embaln.lo embcom.lo embcons.lo embdata.lo embdbi.lo \
embdmx.lo embdomain.lo embest.lo embexit.lo embgroup.lo \
embiep.lo embindex.lo embinit.lo embmat.lo embmisc.lo \
diff -Nurd -x'*~' EMBOSS-5.0.0.orig/plplot/Makefile.in 
EMBOSS-5.0.0/plplot/Makefile.in
--- EMBOSS-5.0.0.orig/plplot/Makefile.in2007-07-12 06:53:36.0 
-0400
+++ EMBOSS-5.0.0/plplot/Makefile.in 2007-12-03 01:15:17.0 -0500
@@ -54,7 +54,7 @@
 am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(pkgincludedir)"
 libLTLIBRARIES_INSTALL = $(INSTALL)
 LTLIBRARIES = $(lib_LTLIBRARIES)
-libeplplot_la_LIBADD =
+libeplplot_la_LIBADD = $(X_LIBS) -lX11 -lgd
 am__objects_1 = pdfutils.lo plargs.lo plbox.lo plcont.lo plcore.lo \
plctrl.lo plcvt.lo pldtik.lo plfill.lo plhist.lo plline.lo \
plmap.lo plot3d.lo plpage.lo plsdef.lo plshade.lo plsym.lo \
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Daniel Macks
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
see what symbols are unresolved. The makefiles all appear to know the
libs that would be needed, but intentionally avoid dynamically linking
them on darwin (and don't even pass the flags correctly on most other
platforms because they didn't read the automake or libtool manual).

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks

Preparing...
g++ -all_load -multiply_defined suppress -bind_at_load /tmp/vSdsgacKlN.c -o 
/tmp/z82JuI69tD.o

Testing package emboss-ajax5-dev...

Examining /sw/lib/libajaxg.dylib...
g++ -all_load -multiply_defined suppress -bind_at_load /tmp/vSdsgacKlN.c -o 
/tmp/z82JuI69tD.o /sw/lib/libajaxg.a /sw/lib/EMBOSS/libajaxg.5.dylib 
/usr/lib/libSystem.B.dylib
ld: Undefined symbols:
_ajAcdGetProgram
_ajAcdInit
_ajAcdInitP
_ajCallRegister
_ajCharMatchC
_ajCharMatchCaseC
_ajCharPrefixCaseS
_ajDebug
_ajDegToRad
_ajErr
_ajFileClose
_ajFileNewOut
_ajFmtPrint
_ajFmtPrintAppS
_ajFmtPrintF
_ajFmtPrintS
_ajFmtStr
_ajFmtString
_ajListstrFree
_ajListstrGetLength
_ajListstrNew
_ajListstrPop
_ajListstrPushAppend
_ajMemAlloc
_ajMemCalloc
_ajMemCalloc0
_ajMemFree
_ajNamInit
_ajSeqGetLen
_ajSeqGetNameS
_ajStrAppendC
_ajStrAssignC
_ajStrAssignEmptyC
_ajStrAssignEmptyS
_ajStrAssignS
_ajStrDel
_ajStrGetCharLast
_ajStrGetLen
_ajStrGetPtr
_ajStrInsertC
_ajStrInsertS
_ajStrKeepRange
_ajStrMatchCaseC
_ajStrNewC
_ajTimeDel
_ajTimeNewToday
_ajTimeNewTodayFmt
_ajUser
_c_pladv
_c_plbox
_c_plcol0
_c_plend
_c_plerrx
_c_plerry
_c_plfill
_c_plgchr
_c_plgpage
_c_plinit
_c_pljoin
_c_plline
_c_pllsty
_c_plmtex
_c_plpoin
_c_plpsty
_c_plptex
_c_plschr
_c_plscol0
_c_plsdev
_c_plsori
_c_plspage
_c_plssub
_c_plvpor
_c_plvsta
_c_plwid
_c_plwind
_c_plxsfnam
_plsc
_plstrl

Examining /sw/lib/libajax.dylib...
g++ -all_load -multiply_defined suppress -bind_at_load /tmp/vSdsgacKlN.c -o 
/tmp/z82JuI69tD.o /sw/lib/libajax.a /sw/lib/EMBOSS/libajax.5.dylib 
/usr/lib/libSystem.B.dylib

Testing package emboss-eplplot3-dev...

Examining /sw/lib/libeplplot.dylib...
g++ -all_load -multiply_defined suppress -bind_at_load /tmp/vSdsgacKlN.c -o 
/tmp/z82JuI69tD.o /sw/lib/libeplplot.a /sw/lib/EMBOSS/libeplplot.3.dylib 
/usr/lib/libSystem.B.dylib
ld: Undefined symbols:
_XAllocColor
_XAllocColorCells
_XAllocNamedColor
_XCheckWindowEvent
_XClearWindow
_XCloseDisplay
_XCopyArea
_XCreateColormap
_XCreateFontCursor
_XCreateGC
_XCreatePixmap
_XCreateWindow
_XDefineCursor
_XDestroyWindow
_XDrawLine
_XDrawLines
_XFillPolygon
_XFillRectangle
_XFlush
_XFree
_XFreeColors
_XFreeGC
_XFreePixmap
_XGetErrorText
_XGetGeometry
_XGetImage
_XGetVisualInfo
_XLookupString
_XMapRaised
_XOpenDisplay
_XPending
_XPutImage
_XQueryColors
_XQueryPointer
_XSelectInput
_XSetBackground
_XSetErrorHandler
_XSetForeground
_XSetFunction
_XSetLineAttributes
_XSetStandardProperties
_XSetWindowBackground
_XSetWindowColormap
_XStoreColor
_XSync
_XSynchronize
_XUndefineCursor
_XWarpPointer
_XWindowEvent
_gdFree
_gdImageColorAllocate
_gdImageColorDeallocate
_gdImageCreate
_gdImageCreateTrueColor
_gdImageDestroy
_gdImageFilledPolygon
_gdImageFilledRectangle
_gdImageGifPtr
_gdImageLine
_gdImagePngPtrEx
_gdImageSetAntiAliased
_gdImageSetThickness

Testing package emboss-nucleus5-dev...

Examining /sw/lib/libnucleus.dylib...
g++ -all_load -multiply_defined suppress -bind_at_load /tmp/vSdsgacKlN.c -o 
/tmp/z82JuI69tD.o /sw/lib/libnucleus.a /sw/lib/EMBOSS/libnucleus.5.dylib 
/usr/lib/libSystem.B.dylib
ld: Undefined symbols:
_ajAZToInt
_ajAlignDefineSS
_ajAlignSetGapR
_ajAlignSetMatrixFloat
_ajAlignSetRange
_ajAlignSetScoreR
_ajDebug
_ajFmtPrintAppS
_ajFmtPrintF
_ajMemAlloc
_ajMemFree
_ajMessCrashFL
_ajMessSetErr
_ajSeqAssignAccS
_ajSeqAssignDescS
_ajSeqAssignNameS
_ajSeqAssignUsaS
_ajSeqDel
_ajSeqGapStandard
_ajSeqGetAccS
_ajSeqGetDescS
_ajSeqGetLen
_ajSeqGetNameS
_ajSeqGetOffend
_ajSeqGetOffset
_ajSeqGetSeqC
_ajSeqGetUsaS
_ajSeqIsReversed
_ajSeqNewNameS
_ajSeqNewRangeC
_ajSeqcvtGetCodeK
_ajSeqstrCountGaps
_ajStrAppendC
_ajStrAppendK
_ajStrAppendS
_ajStrAssignC
_ajStrAssignK
_ajStrAssignS
_ajStrAssignSubC
_ajStrCalcCountK
_ajStrDel
_ajStrDelStatic
_ajStrFmtUpper
_ajStrGetLen
_ajStrGetPtr
_ajStrInsertK
_ajStrNewC
_ajStrReverse
_ajStrSetRes
_ajMemCalloc
_ajMemCalloc0
_ajStrCmpS
_ajStrVcm

Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Jean-François Mertens

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
>> suggested _ it doesn't take that long ..  :)
>
> Actually there are dozes of binaries in emboss (it's a suite of  
> programs). Only three of them have the word 'emboss' in them. If I  
> change the test to:
>
> dpkg -L emboss | grep bin | xargs file | fgrep 'Mach-O' | cut -f1 -d:
>
> I still get a long list, assuming that I didn't make an error. So  
> it would take some more time to go through all of them one by one :)

No .. That's why the file in question was labeled "$f" in :
> dpkg -S emboss | xargs file | fgrep 'Mach-O' | cut -f1 -d:
> will give you the list of all binaries in your pkg
>
> Then, for each of those in turn, say $f, run
>
> nm -mgu $f | fgrep -v ' (from '


to do in fact :

for f in `dpkg -S emboss | xargs file | fgrep 'Mach-O' | cut -f1 -d:` \
do echo $f;
nm -mgu $f | fgrep -v ' (from '
done

Cheers,

JF
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Jean-François Mertens
>
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 _ it doesn't take that long ..  :)

JF

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Koen van der Drift

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.build/bio-emboss-pm588-5.0.0.1-1/ 
>> Bio-
>> Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 2): Symbol  
>> not
>> found: _XAllocColor
>>   Referenced from: /sw/lib/EMBOSS/libeplplot.3.dylib
>>   Expected in: dynamic lookup
>>  at t/1.t line 11
>> Compilation failed in require at t/1.t line 11.
>
> Did you check with otool -L that libeplplot Any suggestions on how I  
> can make it load libX11loads libX11?

Hmm, no it doesn't:

$ oTool -L libeplplot.*
libeplplot.3.2.7.dylib:
/sw/lib/EMBOSS/libeplplot.3.dylib (compatibility version 6.0.0,  
current version 6.7.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 111.0.0)
libeplplot.3.dylib:
/sw/lib/EMBOSS/libeplplot.3.dylib (compatibility version 6.0.0,  
current version 6.7.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 111.0.0)
libeplplot.dylib:
/sw/lib/EMBOSS/libeplplot.3.dylib (compatibility version 6.0.0,  
current version 6.7.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 111.0.0)


Any suggestions on how I can make it load libX11?

thanks,

- Koen.




-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] cvs up : "Cannot allocate memory"

2007-12-02 Thread Jean-François Mertens

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

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Peter O'Gorman
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(/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, 1):  
>> Symbol not found: _XS_Bio__Emboss_ajStrTokenCount
>>  Referenced from: /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
>>  Expected in: dynamic lookup
>> at t/1.t line 11
> 
> 
> 
> OK, I solved that by commenting out the following line in the test file:
> 
> BEGIN { delete $ENV{PERL_DL_NONLAZY}; };

Yes, this makes it pass RTLD_NOW to dlopen() which is similar to setting
DYLD_BIND_AT_LAUNCH. It should work with this set, if it does not it
means there is a missing lib or symbol when linking the loadable bundle.

> 
> 
> 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.build/bio-emboss-pm588-5.0.0.1-1/Bio- 
> Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 2): Symbol not  
> found: _XAllocColor
>Referenced from: /sw/lib/EMBOSS/libeplplot.3.dylib
>Expected in: dynamic lookup
>   at t/1.t line 11
> Compilation failed in require at t/1.t line 11.

Did you check with otool -L that libeplplot loads libX11?

Peter
-- 
Peter O'Gorman
http://pogma.com

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] cvs up : "Cannot allocate memory"

2007-12-02 Thread Daniel Macks
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 explicitly /usr/bin/cvs, so it is not  
> due to fink's cvs pkg.
> This happens even when local memory usage is low _ say 1.4 out of 2 G.
> 
> In general when retrying, especially dir after dir and with a naked  
> 'cvs up' without adornations,
> things go away and one gets through. Tonight not...
> 
> The ref to "/cvsroot/fink/dists/" suggests it may be either a memory  
> problem or an error
> on the other side..
> (In general I get this on rather big dirs _ eg, 'libs' _ but tonight  
> even on smaller ones like crypto)
> 
> Anyone else experiencing this ?
> Is it really a sourceforge problem ?

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.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] cvs up : "Cannot allocate memory"

2007-12-02 Thread David Reiser

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: 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 when local memory
>>> usage is low _ say 1.4 out of 2 G.
>>>
>>> In general when retrying, especially dir after dir and with a naked
>>> 'cvs up' without adornations, things go away and one gets through.
>>> Tonight not...
>>>
>>> The ref to "/cvsroot/fink/dists/" suggests it may be either a
>>> memory problem or an error on the other side.. (In general I get
>>> this on rather big dirs _ eg, 'libs' _ but tonight even on smaller
>>> ones like crypto)
>>>
>>> Anyone else experiencing this ? Is it really a sourceforge problem
>>> ?
>>>
>>> JF
>>>
>>> PS: crypto finally got through, after ~8 iterations
>> I have, and others have talked about it on IRC.
>
> And ?  _ the conclusion of the talking ?
>
> JF
Unfortunately the usual conclusion: sourceforge has issues that aren't  
communicated well or resolved quickly.

Dave
--
David Reiser
[EMAIL PROTECTED]





-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] cvs up : "Cannot allocate memory"

2007-12-02 Thread Jean-François Mertens

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/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 when local memory
>> usage is low _ say 1.4 out of 2 G.
>>
>> In general when retrying, especially dir after dir and with a naked
>>  'cvs up' without adornations, things go away and one gets through.
>> Tonight not...
>>
>> The ref to "/cvsroot/fink/dists/" suggests it may be either a
>> memory problem or an error on the other side.. (In general I get
>> this on rather big dirs _ eg, 'libs' _ but tonight even on smaller
>> ones like crypto)
>>
>> Anyone else experiencing this ? Is it really a sourceforge problem
>> ?
>>
>> JF
>>
>> PS: crypto finally got through, after ~8 iterations
> I have, and others have talked about it on IRC.

And ?  _ the conclusion of the talking ?

JF
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] cvs up : "Cannot allocate memory"

2007-12-02 Thread Alexander Hansen
-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 using explicitly /usr/bin/cvs, so it is
> not due to fink's cvs pkg. This happens even when local memory
> usage is low _ say 1.4 out of 2 G.
>
> In general when retrying, especially dir after dir and with a naked
>  'cvs up' without adornations, things go away and one gets through.
> Tonight not...
>
> The ref to "/cvsroot/fink/dists/" suggests it may be either a
> memory problem or an error on the other side.. (In general I get
> this on rather big dirs _ eg, 'libs' _ but tonight even on smaller
> ones like crypto)
>
> Anyone else experiencing this ? Is it really a sourceforge problem
> ?
>
> JF
>
> PS: crypto finally got through, after ~8 iterations
I have, and others have talked about it on IRC.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHU3H3B8UpO3rKjQ8RArXqAJ9LEO5iTyPe6llFsDQLGEJJywGoSQCfbSB8
ojF+TIcycqU4afzigWfiH8s=
=yNIT
-END PGP SIGNATURE-


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


[Fink-devel] cvs up : "Cannot allocate memory"

2007-12-02 Thread Jean-François Mertens
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 when local memory usage is low _ say 1.4 out of 2 G.

In general when retrying, especially dir after dir and with a naked  
'cvs up' without adornations,
things go away and one gets through. Tonight not...

The ref to "/cvsroot/fink/dists/" suggests it may be either a memory  
problem or an error
on the other side..
(In general I get this on rather big dirs _ eg, 'libs' _ but tonight  
even on smaller ones like crypto)

Anyone else experiencing this ?
Is it really a sourceforge problem ?

JF

PS: crypto finally got through, after ~8 iterations

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Koen van der Drift

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 /sw/lib
>
> Thanks Peter,
>
> The grep command revealed two broken aliases. One of them was from  
> the emboss package, which I fixed, and I don't get the error  
> anymore. The other one was lebecpg.4.dylib, which seems to belong to  
> postgresql. I think I once installed it, but right now I don't have  
> that installed anymore. Not sure why it is still on my system and  
> why it would contain plsc, maybe just a coincidence.
>
> 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(/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, 1):  
> Symbol not found: _XS_Bio__Emboss_ajStrTokenCount
>  Referenced from: /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
>  Expected in: dynamic lookup
> at t/1.t line 11



OK, I solved that by commenting out the following line in the test file:

BEGIN { delete $ENV{PERL_DL_NONLAZY}; };

This does the following (see http://www.perl.com/lpt/a/520):   
[quote]... it passes a flag to dlopen which attempts to ensure that  
all functions are relocated as soon as the shared object is loaded.  
Sounds complicated? In the normal, "lazy" operation of the dynamic  
loader, the loader doesn't actually load all the functions from the  
library file into memory at one go - instead, it merely notices that  
it has a bunch more functions available; when a function is called, it  
loads up the appropriate part of the object into memory, and jumps to  
it. (Not entirely unlike the behaviour of use autouse or AutoSplit.)
Setting [PERL_DL_NONLAZY] forces the loader to load up all functions  
at once, so that it can ensure that it really does have code for all  
the functions it claims to have code for; this is usually what you  
want to do when testing.[/quote]


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.build/bio-emboss-pm588-5.0.0.1-1/Bio- 
Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 2): Symbol not  
found: _XAllocColor
   Referenced from: /sw/lib/EMBOSS/libeplplot.3.dylib
   Expected in: dynamic lookup
  at t/1.t line 11
Compilation failed in require at t/1.t line 11.

As I understand, _XAllocColor is part of libX1, and I have X11 and the  
X11SDK installed from the Leopard DVD. I re-installed both, rebuild  
emboss, and then tried bio-emboss-pm588 again, but still the same error.

Any clues?

thanks,

- Koen.










-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] Failed: phase compiling: oleo-1.99.16-1021 failed

2007-12-02 Thread Daniel Macks
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 install it or use --without-motif
> checking for Xbae... libraries test link failed, headers test link failed
[...]
> Looking at config.log, I see a lot of
> 
> error: Not a directory - unable to create 'conftest.dSYM/Contents' bundle 
> directory.

Those are normal on Leopard.

> Note that I checked that Xbae is installed.

The important part of config.log is the section dealing with the
actual Xbae test. The first relevant line in that file is probably:

  configure:3466: checking for Xbae

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


[Fink-devel] Failed: phase compiling: oleo-1.99.16-1021 failed

2007-12-02 Thread Dominique Dhumieres
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 failed, headers test link failed
### execution of ac_cv_lib_mysqlclient_mysql_connect=yes failed, exit code 1
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-oleo-1.99.16-1021
(Reading database ... 122679 files and directories currently installed.)
Removing fink-buildlock-oleo-1.99.16-1021 ...
Failed: phase compiling: oleo-1.99.16-1021 failed

Looking at config.log, I see a lot of

error: Not a directory - unable to create 'conftest.dSYM/Contents' bundle 
directory.

Note that I checked that Xbae is installed.

TIA

Dominique

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] Failed: phase compiling: xmhtml-1.1.7-4 failed on Leopard

2007-12-02 Thread Dominique Dhumieres
> 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, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] dlopen symbol not found

2007-12-02 Thread Koen van der Drift

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 aliases. One of them was from the  
emboss package, which I fixed, and I don't get the error anymore. The  
other one was lebecpg.4.dylib, which seems to belong to postgresql. I  
think I once installed it, but right now I don't have that installed  
anymore. Not sure why it is still on my system and why it would  
contain plsc, maybe just a coincidence.

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(/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, 1): Symbol not  
found: _XS_Bio__Emboss_ajStrTokenCount
   Referenced from: /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
   Expected in: dynamic lookup
  at t/1.t line 11

Using the grep command, ajStrTokenCount is in /sw/lib/libajax*, which  
is installed. I'll have another look at it later today.

cheers,

- Koen.






-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel


Re: [Fink-devel] problem with octave ?

2007-12-02 Thread Jean-François Mertens
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.be>  
> writes:
>
>>
>> Putting this to fink-devel...
>>
>> Since I won't have time to delve into this for the next couple of  
>> days,
>> please have a look at tracker item
>> https://sourceforge.net/tracker/?
>> func=detail&atid=414256&aid=1825780&group_id=17203
>>
>> JF Mertens
>
>
> I have been playing with all of this for afew days on both Intel and
> PPC, with Mac OS X 10.4.11
>
> About octave-forge : there should be a build-depend on libssh2 or
> libssh2.1, as it is required for building package octcdf.
>
> What I have tested:
>
> Set 1:
> octave   2.9.17-1
> octave-forge 20071014-2
> (always built with g95)
>
> Set 2:
> octave2.9.17-2
> octave-forge  20071014-4
> (built with g95 or gfortran depending on what is installed)
>
> Set 1 works on both Intel and PPC, and is what people should use  
> for now
> on Mac OS X 10.4.
>
> For Set 2, if octave is built WITHOUT gfortran (i.e. if it is not
> installed, even with ConfigureParams: --with-f77=%p/bin/gfortran, but
> g95 is installed), then everything is fine, BUT building octave-forge
> writes directly in /sw/share /octave, wich is not good, as the .deb  
> does
> not contain anything actually, so it is better to stay with rev. 2 of
> this package.
> Now if gfortran is installed, octave compiles fine, but I get a
> seg-fault when building octave-forge on Intel, I did not try on PPC,
> maybe next week.
>

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel