On Feb 2, 2:32 am, "Justin C. Walker" <[EMAIL PROTECTED]> wrote:
> Hi, Michael,
>
> Sorry for the delay in responding. I've been other-directed
> recently :-}
>
> On Jan 31, 2008, at 7:03 PM, mabshoff wrote:
>
> >> Initial build blew up because of a conflict with the 'gnutls' package
> >> and a locally-installed Guile package. I rebuilt with a modified/
> >> restricted PATH variable (set to the bare minimum). Sage built
> >> without a problem. Ran 'make test', and got one error, the 'maple'
> >> interface problem. I applied the patch from Trac #1926 and reran all
> >> the tests with no problems.
>
> >> Trac #2003 documents this build failure.
>
> > there is an updated spkg linked from #2003. Could you try to build
> > that because I am not sure if it will work.
>
> FWIW, I did a quick-hack check by just running "configure --enable-
> guile=no" and that seemed to have the right effect (without it, I got
> complaints; with it, no complaints and nothing about guile).
>
> > The proper fix in my eyes
> > is to edit one of the Makefile.in not to enter the guile subdirectory.
>
> I will try the updated spkg with rc4 this weekend and let you know.
>
> > Long term there need to be a couple fixes:
> > * add a proper config option not to build guile, i.e. --without-guile
>
> I'm not sure it's needed, but if they'll take it upstream that's good.
Well, if "--enable-guile=no" works then that is fine. The new spkg at
#2003 does exactly that (as you suggested)
> > * fix the guile build on OSX, i.e. I assume you need to link against
> > the *dylib* instead of *so*
IIRC the problem seems to be that they dlopen some library and that
doesn't work as expected on OSX with the "so" extension. The GNUTLS
python bindings have that problem, too, and we have a patch for it,
that I plan to send upstream at some point.
> Typically, a shared library is called "foo.dylib", but the main thing
> is that the linker know the correct name :-} Of course if you name
> it implicitly ("-lmylib" vs. "/path/to/libmylib.
> {dylib,so,ThisIsALibraryDammit}"), that matters :-}
Yep, but dlopen still has the naming issue. If you look at rpy for
example you will see simliar problems on Cygwin.
> I assume that this is the cause here, but from the error message, I
> can't tell for sure.
>
> > * fix the guile build on Cygwin, but that will be a little more
> > effort
>
> Does "working on Cygwin" mean that it works in any case where an
> existing installation is found?
The guile extension in GNUTLS is very, very badly broken at the
moment. As a matter of fact GNUTLS doesn't even compile on Cygwin at
all (neither 1.6 nor 2.2.1), but I also have a patch that fixes that.
It also needs to be pushed upstream.
> Thanks!
>
> Justin
>
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
