Opened 8 years ago

Closed 3 years ago

#14491 closed enhancement (duplicate)

Add FreeBSD as a supported platform

Reported by: kcrisman Owned by: pjeremy
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: porting: BSD Keywords:
Cc: jdemeyer, stephen, jpflori, leif, cremona Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

Thanks to Stephen Montgomery-Smith's excellent work maintaining the port at http://www.freebsd.org/cgi/cvsweb.cgi/ports/math/sage/ we are nearly there; this ticket would be to allow someone to download a Sage tarball on FreeBSD and (with appropriate prerequisites) type make and have it build and work.

Since #14406 and #14447 show us how to do it for adding Cygwin, we could probably cut and paste much of those.

Change History (40)

comment:1 Changed 8 years ago by leif

  • Cc leif added

comment:2 follow-ups: Changed 8 years ago by stephen

I am having some significant troubles building sage-5.9.beta5. It is due to the fact that there is more than one version of the compiler being used, and various libraries either being built or not being built, or linkers getting pre-built libraries from the wrong place. The exact nature of the error depends upon whether I use the FreeBSD versions of gcc-4.7 and atlas or the versions that come with sage. Both give errors, but different errors. I know that given time I can work it out, but I don't have time right now.

For this reason, when the release version of sage-5.9 comes out, I am unlikely to upgrade the sage port. We should delay in adding FreeBSD as a supported platform.

Also, for ANY version of the gcc-4.7 compiler to work (either the one that comes with FreeBSD, or the one that comes with sage), the following patch is needed for FreeBSD:

--- eclib-20120830/src/libsrc/eclib/xmod.h-orig 2013-04-08 17:16:56.000000000 +0000
+++ eclib-20120830/src/libsrc/eclib/xmod.h      2013-04-08 18:14:26.000000000 +0000
@@ -20,7 +20,8 @@
 // Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
 //
 //////////////////////////////////////////////////////////////////////////
-
+
+#include <stdint.h>; // int64_t for FreeBSD

 // All are inline functions, there's no .cc file

comment:3 in reply to: ↑ 2 Changed 8 years ago by kcrisman

For this reason, when the release version of sage-5.9 comes out, I am unlikely to upgrade the sage port. We should delay in adding FreeBSD as a supported platform.

That's fine, I just felt like opening this ticket since so many of the tickets had been closed and a couple others just need us to package up your fixes (pycrypto and python). Never hurts to have it available for people to comment on.

comment:4 in reply to: ↑ 2 ; follow-up: Changed 8 years ago by kcrisman

  • Cc cremona added

Also, for ANY version of the gcc-4.7 compiler to work (either the one that comes with FreeBSD, or the one that comes with sage), the following patch is needed for FreeBSD:

I've reported this upstream here and cc:ed the author of eclib.

comment:5 in reply to: ↑ 4 Changed 8 years ago by leif

Replying to kcrisman:

Also, for ANY version of the gcc-4.7 compiler to work (either the one that comes with FreeBSD, or the one that comes with sage), the following patch is needed for FreeBSD:

I've reported this upstream here and cc:ed the author of eclib.

We already discussed that on sage-devel (and John is aware of that); not sure whether there's already a ticket, but IIRC Jean-Pierre also fixed that, so he'll know...

comment:6 Changed 8 years ago by jpflori

Yes we discussed the eclib issue extensively on sage-devel and John is aware of it. Not sure though he already commited anything upstream.

I'll be in Warwick in two weeks for the FLINT workshop, so if that can give him enough motivation to push a patch :)

comment:7 Changed 8 years ago by jpflori

And as far as building sage 5.9 on FreeBSD is concerned, I remember being mostly successful, using only Sage provided sutff (including building GCC), having to work around some issues with ATLAS (3.10, I gave up 3.8), eclib as you could guess, and surely other things but that was some weeks ago and was pushed out of my head (or at least I don't remember right now, everything is surely written on sage-devel or sage-release as I ususally do that to circumvent potential human brain failures, not sure where though).

comment:8 Changed 8 years ago by jpflori

Of course I also needed the fixes from stephen: the pycrypto fixes to build pycrypto, I did not need the python fix to build the spkg, not sure it was needed though for dependencies or for runtime.

comment:9 Changed 8 years ago by jpflori

Here is the relevant link on sage-devel for the eclib and ATLAS issues: https://groups.google.com/d/msg/sage-devel/b8ZGqE6Y7Vg/A-QIXAp2CRYJ

For ATLAS its the same thread crap as on other exotic platform, and IIRC I worked around the problem by using static libraries. Not sure upstream ATLAS is ready to solve the shared libraries issues quickly...

comment:10 Changed 8 years ago by stephen

jpflori - which sage beta version were you able to build? The use of gcc-4.7 was only introduced very recently, maybe beta3.

comment:11 in reply to: ↑ 2 Changed 8 years ago by kcrisman

Also, for ANY version of the gcc-4.7 compiler to work (either the one that comes with FreeBSD, or the one that comes with sage), the following patch is needed for FreeBSD:

John says at the eclib github site,

Can you see if it works OK to add this line in the file libsrc/eclib/interface.h, around line 50? I think that's a better place for it: the int64_t type is referred to in libsrc/smat.cc, smat_elim.cc and svec.cc in the current version.

comment:12 follow-ups: Changed 8 years ago by stephen

OK, two pieces of good news.

  1. The patch suggested by John worked.
    --- eclib-20120830/src/libsrc/eclib/interface.h-orig    2013-04-26 23:46:24.000000000 +0000
    +++ eclib-20120830/src/libsrc/eclib/interface.h 2013-04-26 23:47:09.000000000 +0000
    @@ -48,6 +48,7 @@
     #include <iterator>
     using namespace std;
     #include "templates.h"
    +#include <stdint.h>
    
     #ifndef MININT
     #define MININT numeric_limits<int>::min()
    
  1. I was able to solve the library problems. I used the FreeBSD gcc-4.7, and the FreeBSD atlas. Then I linked everything in /usr/local/lib/gcc47 to $SAGE_ROOT/local/lib before starting the build of sage. The problem was in the build of r-2.15.2.p2. At some point during the build, it runs R, which is a script. My guess is that it tries to run the binary R, and the binary gets libgcc_s.so.1 from /lib instead of /usr/local/lib/gcc47. And unfortunately the version in /lib is incompatible with /usr/local/lib/gcc47/libgfortran.so.3.

So when sage-5.9 comes out, I will be able to update the FreeBSD port.

comment:13 in reply to: ↑ 12 Changed 8 years ago by cremona

Replying to stephen:

OK, two pieces of good news.

  1. The patch suggested by John worked.
    --- eclib-20120830/src/libsrc/eclib/interface.h-orig    2013-04-26 23:46:24.000000000 +0000
    +++ eclib-20120830/src/libsrc/eclib/interface.h 2013-04-26 23:47:09.000000000 +0000
    @@ -48,6 +48,7 @@
     #include <iterator>
     using namespace std;
     #include "templates.h"
    +#include <stdint.h>
    
     #ifndef MININT
     #define MININT numeric_limits<int>::min()
    

Excellent, I will make that change to eclib so that the next spkg will have it in.

comment:14 in reply to: ↑ 12 ; follow-ups: Changed 8 years ago by kcrisman

  1. I was able to solve the library problems. I used the FreeBSD gcc-4.7, and the FreeBSD atlas. Then I linked everything in /usr/local/lib/gcc47 to $SAGE_ROOT/local/lib before starting the build of sage. The problem was in the build of r-2.15.2.p2. At some point during the build, it runs R, which is a script. My guess is that it tries to run the binary R, and the binary gets libgcc_s.so.1 from /lib instead of /usr/local/lib/gcc47. And unfortunately the version in /lib is incompatible with /usr/local/lib/gcc47/libgfortran.so.3.

Can you pinpoint exactly where that happens? I'm not seeing anything obvious in the spkg-install, and we should have all R-related env vars now set properly so that only Sage stuff is seen... or maybe not?

So when sage-5.9 comes out, I will be able to update the FreeBSD port.

Great!

comment:15 in reply to: ↑ 14 Changed 8 years ago by leif

Replying to kcrisman:

  1. I was able to solve the library problems. I used the FreeBSD gcc-4.7, and the FreeBSD atlas. Then I linked everything in /usr/local/lib/gcc47 to $SAGE_ROOT/local/lib before starting the build of sage. The problem was in the build of r-2.15.2.p2. At some point during the build, it runs R, which is a script. My guess is that it tries to run the binary R, and the binary gets libgcc_s.so.1 from /lib instead of /usr/local/lib/gcc47. And unfortunately the version in /lib is incompatible with /usr/local/lib/gcc47/libgfortran.so.3.

Can you pinpoint exactly where that happens? I'm not seeing anything obvious in the spkg-install, and we should have all R-related env vars now set properly so that only Sage stuff is seen... or maybe not?

I had similar issues in the past with R on the Skynet Solaris machines; at some point, an R script (not Sage's spkg-install!) messed up LD_LIBRARY_PATH, such that an outdated version of libgcc_s got picked up (although I don't recall whether that led to libgfortran failing to load) .

comment:16 in reply to: ↑ 14 ; follow-up: Changed 8 years ago by stephen

Replying to kcrisman:

  1. I was able to solve the library problems. I used the FreeBSD gcc-4.7, and the FreeBSD atlas. Then I linked everything in /usr/local/lib/gcc47 to $SAGE_ROOT/local/lib before starting the build of sage. The problem was in the build of r-2.15.2.p2. At some point during the build, it runs R, which is a script. My guess is that it tries to run the binary R, and the binary gets libgcc_s.so.1 from /lib instead of /usr/local/lib/gcc47. And unfortunately the version in /lib is incompatible with /usr/local/lib/gcc47/libgfortran.so.3.

Can you pinpoint exactly where that happens? I'm not seeing anything obvious in the spkg-install, and we should have all R-related env vars now set properly so that only Sage stuff is seen... or maybe not?

When were these changes made? I tried to reproduce the error using sage-5.9.rc1, and now the error doesn't happen. I think I was detecting the error trying to build beta5.

comment:17 in reply to: ↑ 16 ; follow-up: Changed 8 years ago by leif

Replying to stephen:

Replying to kcrisman:

Can you pinpoint exactly where that happens? I'm not seeing anything obvious in the spkg-install, and we should have all R-related env vars now set properly so that only Sage stuff is seen... or maybe not?

When were these changes made? I tried to reproduce the error using sage-5.9.rc1, and now the error doesn't happen. I think I was detecting the error trying to build beta5.

The only recent change I'm aware of was #9668, indeed just merged into Sage 5.9.rc0.

comment:18 in reply to: ↑ 17 Changed 8 years ago by kcrisman

Can you pinpoint exactly where that happens? I'm not seeing anything obvious in the spkg-install, and we should have all R-related env vars now set properly so that only Sage stuff is seen... or maybe not?

When were these changes made? I tried to reproduce the error using sage-5.9.rc1, and now the error doesn't happen. I think I was detecting the error trying to build beta5.

The only recent change I'm aware of was #9668, indeed just merged into Sage 5.9.rc0.

Bingo, and that is exactly what I was talking about! I'm surprised that never gave you trouble before, as that hard-coding and R variable setting has been a problem for a long time. But if it is indeed gone, that is great.


Stephen, assuming the eclib thing and this thing are fixed (and assuming that #12399 and #12400 eventually get in, and that #9600 is bogus nowadays), what would remain for one to build Sage without using your port but by simply unpacking and typing "make" (having all prereqs)? Not that this would be the default for people on FreeBSD - like someone on Gentoo would use Sage-on-Gentoo, someone on FreeBSD would use your port - but we would want it to be possible.

comment:19 follow-ups: Changed 8 years ago by stephen

There were some old instructions that pjeremy had on how to build sage, and some of those are still necessary.

  1. FreeBSD comes with a totally incompatible version of make, so you have to link make to gmake in $SAGE_ROOT/local/bin.
  1. You also have to build the FreeBSD version of gcc47 and atlas. And you need to put wrappers to gcc, gfortran and g++ in SAGE_ROOT/local/bin.
  1. I did try building the gcc that comes with sage, and that worked. But first it has to build mpir, and unfortunately the standard gcc that comes with FreeBSD-8.x broke. I haven't tried clang which comes with FreeBSD-9.x. gcc46 was capable of building mpir, but it seemed like a bad deal to build gcc46 just to build one of the prerequisites for building the sage version of gcc.
  1. The sage version of atlas failed to work. I didn't explore this issue too far, because the FreeSBD version of atlas works. But it might well be #9600, so don't close it yet.

comment:20 in reply to: ↑ 19 Changed 8 years ago by jpflori

Replying to stephen:

There were some old instructions that pjeremy had on how to build sage, and some of those are still necessary.

  1. FreeBSD comes with a totally incompatible version of make, so you have to link make to gmake in $SAGE_ROOT/local/bin.

The need for a GNU make is already documented in the source install guide, of course it would be nice to add pointers on how to actually install it on FreeBSD.

  1. You also have to build the FreeBSD version of gcc47 and atlas. And you need to put wrappers to gcc, gfortran and g++ in SAGE_ROOT/local/bin.
  1. I did try building the gcc that comes with sage, and that worked. But first it has to build mpir, and unfortunately the standard gcc that comes with FreeBSD-8.x broke. I haven't tried clang which comes with FreeBSD-9.x. gcc46 was capable of building mpir, but it seemed like a bad deal to build gcc46 just to build one of the prerequisites for building the sage version of gcc.
  1. The sage version of atlas failed to work. I didn't explore this issue too far, because the FreeSBD version of atlas works. But it might well be #9600, so don't close it yet.

When I have some time, I'll try to build Sage 5.10 with the new ATLAS and report on my success in using the Sage provided GCC and ATLAS.

comment:21 in reply to: ↑ 19 ; follow-up: Changed 8 years ago by leif

Replying to stephen:

  1. I did try building the gcc that comes with sage, and that worked. But first it has to build mpir, and unfortunately the standard gcc that comes with FreeBSD-8.x broke. I haven't tried clang which comes with FreeBSD-9.x.

MPIR (2.6.0) currently won't build with clang either (for no real reason; configure just bails out because MPIR thinks it was [a broken version of] GCC). There is some Sage trac ticket I was going to fix this, but I haven't even uploaded a patch nor submitted it upstream yet. (I do have patches to upstream's configure[.in] somewhereTM... With these, make check passed for me with different versions of clang, and even on MacOS X, with Apple's dead old 1.7 version IIRC.)

gcc46 was capable of building mpir, but it seemed like a bad deal to build gcc46 just to build one of the prerequisites for building the sage version of gcc.

comment:22 in reply to: ↑ 21 Changed 8 years ago by leif

Replying to leif:

Replying to stephen:

  1. I did try building the gcc that comes with sage, and that worked. But first it has to build mpir, and unfortunately the standard gcc that comes with FreeBSD-8.x broke. I haven't tried clang which comes with FreeBSD-9.x.

MPIR (2.6.0) currently won't build with clang either (for no real reason; configure just bails out because MPIR thinks it was [a broken version of] GCC). There is some Sage trac ticket I was going to fix this, but I haven't even uploaded a patch nor submitted it upstream yet. (I do have patches to upstream's configure[.in] somewhereTM... With these, make check passed for me with different versions of clang, and even on MacOS X, with Apple's dead old 1.7 version IIRC.)

I at least found the ticket now: #13948

comment:23 Changed 8 years ago by jpflori

So I've relaunched builds on the two virtual machines running FreeBSD on GCC Compile Farm, one is FreeBSD 8.3 amd64, the other FreeBSD 9.0 x86. Here is what I had to do to get Sage 5.9 to build so far, mostly on the 8.3 amd64 system (not finished yet), ATLAS failed on the 9.0 x86 system so some things might be different:

  • install usual prereqs (e.g. gmake),
  • Sage installed its GCC 4.7.2.p1 on both systems, no problems doing so,
  • force iconv installation to let R build,
  • use upstream int64_t fix for eclib,
  • use ATLAS 3.10.1.p1 from #14605, this worked fine on the 8.3 system, but segfaults during tuning (more precisely running "xdfindCE -f res/atlas_cacheedge.h" to determine cache edge, IIRC it used to compile fine on a previous attempt, surely with a different version of GCC compiled by Sage, surely 4.6.3, I've tried to lower optimization levels to build the pieces involved in xdfindCE without success yet, when I try to run it under gdb it just kicks me out of the virtual machine)
  • use pycrypto fix from #12399,
  • elliptic_curve spkg fails because of an sqlite I/O error, surely because of NFS,
  • I've not used python fix from #12400, I'll give it a shot without the fix, but that will surely fail to run "sage -t -force_lib "devel/sage/sage/parallel/decorate.py"" as indicated at http://trac.sagemath.org/sage_trac/ticket/12400#comment:2

The system wide gcc's are:

  • on 9.0 x86
    Using built-in specs.
    Target: i386-undermydesk-freebsd
    Configured with: FreeBSD/i386 system compiler
    Thread model: posix
    gcc version 4.2.1 20070831 patched [FreeBSD]
    
  • on 8.3 amd64
    Using built-in specs.
    Target: amd64-undermydesk-freebsd
    Configured with: FreeBSD/amd64 system compiler
    Thread model: posix
    gcc version 4.2.2 20070831 prerelease [FreeBSD]
    

comment:24 follow-ups: Changed 8 years ago by jpflori

Building the doc repeatedly failed at:

[tensor   ] writing output... [ 25%] index
[tensor   ] writing output... [ 50%] sage/tensor/coordinate_patch
[tensor   ] writing output... [ 75%] sage/tensor/differential_form_element
[tensor   ] writing output... [100%] sage/tensor/differential_forms
[tensor   ] dumping object inventory... done
[tensor   ] build succeeded.
[history_a] loading cross citations... looking for now-outdated files... none found
[history_a] no targets are out of date.

so I tried Stephen's patch:

but then it failed at

[geometry ] writing output... [ 95%] sage/geometry/triangulation/point_configuration
[geometry ] writing output... [100%] sage/rings/polynomial/groebner_fan
[geometry ] dumping object inventory... done
[geometry ] build succeeded.

And indeed Python still fails

sage -t devel/sage/sage/parallel/decorate.py
**********************************************************************
File "devel/sage/sage/parallel/decorate.py", line 526, in sage.parallel.decorate.fork
Failed example:
    g(10^7, m=5)
Exception raised:
    Traceback (most recent call last):
      File "/scratch/jpflori/sage-5.9+freebsd-83-amd64/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 466, in _run
        self.execute(example, compiled, test.globs)
      File "/scratch/jpflori/sage-5.9+freebsd-83-amd64/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 825, in execute
        exec compiled in globs
      File "<doctest sage.parallel.decorate.fork[6]>", line 1, in <module>
        g(Integer(10)**Integer(7), m=Integer(5))
      File "/scratch/jpflori/sage-5.9+freebsd-83-amd64/local/lib/python2.7/site-packages/sage/parallel/decorate.py", line 475, in h
        return list(g([(args, kwds)]))[0][1]
    IndexError: list index out of range
**********************************************************************

comment:25 in reply to: ↑ 24 Changed 8 years ago by jpflori

Replying to jpflori:

Building the doc repeatedly failed at:

[tensor   ] writing output... [ 25%] index
[tensor   ] writing output... [ 50%] sage/tensor/coordinate_patch
[tensor   ] writing output... [ 75%] sage/tensor/differential_form_element
[tensor   ] writing output... [100%] sage/tensor/differential_forms
[tensor   ] dumping object inventory... done
[tensor   ] build succeeded.
[history_a] loading cross citations... looking for now-outdated files... none found
[history_a] no targets are out of date.

so I tried Stephen's patch:

but then it failed at

[geometry ] writing output... [ 95%] sage/geometry/triangulation/point_configuration
[geometry ] writing output... [100%] sage/rings/polynomial/groebner_fan
[geometry ] dumping object inventory... done
[geometry ] build succeeded.

Or not, it just began to go on building the rest of the doc.

comment:26 Changed 8 years ago by jpflori

I've opened #14651 for the numpy/scipy/atlas issue.

comment:27 in reply to: ↑ 24 Changed 8 years ago by jpflori

Replying to jpflori:

Building the doc repeatedly failed at:

[tensor   ] writing output... [ 25%] index
[tensor   ] writing output... [ 50%] sage/tensor/coordinate_patch
[tensor   ] writing output... [ 75%] sage/tensor/differential_form_element
[tensor   ] writing output... [100%] sage/tensor/differential_forms
[tensor   ] dumping object inventory... done
[tensor   ] build succeeded.
[history_a] loading cross citations... looking for now-outdated files... none found
[history_a] no targets are out of date.

so I tried Stephen's patch:

but then it failed at

[geometry ] writing output... [ 95%] sage/geometry/triangulation/point_configuration
[geometry ] writing output... [100%] sage/rings/polynomial/groebner_fan
[geometry ] dumping object inventory... done
[geometry ] build succeeded.

After a quite long time the doc finally got built.

And indeed Python still fails

sage -t devel/sage/sage/parallel/decorate.py
**********************************************************************
File "devel/sage/sage/parallel/decorate.py", line 526, in sage.parallel.decorate.fork
Failed example:
    g(10^7, m=5)
Exception raised:
    Traceback (most recent call last):
      File "/scratch/jpflori/sage-5.9+freebsd-83-amd64/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 466, in _run
        self.execute(example, compiled, test.globs)
      File "/scratch/jpflori/sage-5.9+freebsd-83-amd64/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 825, in execute
        exec compiled in globs
      File "<doctest sage.parallel.decorate.fork[6]>", line 1, in <module>
        g(Integer(10)**Integer(7), m=Integer(5))
      File "/scratch/jpflori/sage-5.9+freebsd-83-amd64/local/lib/python2.7/site-packages/sage/parallel/decorate.py", line 475, in h
        return list(g([(args, kwds)]))[0][1]
    IndexError: list index out of range
**********************************************************************

This is indeed fixed with the patches from #12400.

comment:28 Changed 8 years ago by stephen

I received a suggestion for the FreeBSD port of sage, to use gcc46, and add to the make environment SAGE_INSTALL_GCC=no. This way sage doesn't build its own gcc-4.7, and builds with the gcc-4.6 that comes with FreeBSD.

Everything built and tested well, both for sage-5.9, and sage-5.10.rc0. So I have switched the FreeBSD port to work in this way.

comment:29 follow-up: Changed 8 years ago by stephen

Something new: FreeBSD's binutils port has been updated to version 2.23.2. Since this happened, the cephes patch for FreeBSD only works if the -Wl,--copy-dt-needed-entries option is added to any invocation of gcc or g++ that tries to link with libm.so.

See "Changes in 2.22" in http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/ld/NEWS?rev=1.131.2.1&content-type=text/plain&cvsroot=src&only_with_tag=binutils-binutils-2_23_2

Last edited 8 years ago by stephen (previous) (diff)

comment:30 in reply to: ↑ 29 Changed 8 years ago by leif

Replying to stephen:

Something new: FreeBSD's binutils port has been updated to version 2.23.2. Since this happened, the cephes patch for FreeBSD only works if the -Wl,--copy-dt-needed-entries option is added to any invocation of gcc or g++ that tries to link with libm.so.

Could you explain a bit further, i.e., which parts of Sage are affected by this?

(It would for example be easy to add this flag when building Sage library extension modules, and in some spkg-install files.)

Or in other words, what exactly is broken now?

comment:31 Changed 8 years ago by leif

P.S.:

Would it perhaps help to just make $SAGE_LOCAL/lib/libm.so a linker script that (also) includes the Cephes library?

(On FreeBSD only, of course.)

comment:32 Changed 8 years ago by stephen

leif: to be honest, I don't know the answer to your questions.

First, I don't know what a linker script is.

Secondly, as to what is broken - in the FreeBSD port of sage, I have a wrapper script for gcc that looks something like this:

#!/bin/sh

# This is a wrapper to redirect compiler invokations to the port of gcc that
# contains fortran.  LDFLAGS needs to be added so that the linker knows where
# to find the dynamic libraries.

# If the compiler is invoked with the argument "-v", adding LDFLAGS to the
# arguments results in an error which stops some packages being built.

if [ "x$*" = "x-v" ]; then
  exec %%CC%% "$@"
else
  exec %%CC%% %%LDFLAGS%% -Wl,--copy-dt-needed-entries "$@"
fi

The %%CC%% and %%LDFLAGS%%% are replaced by a sed script to create three scripts called gcc, g++ and gfortran, which are placed in ${SAGE_ROOT}/local/bin.

As I said, I don't know what a linker script is - is it something like my bin scripts?

comment:33 Changed 8 years ago by stephen

I didn't really answer the question as to what was broken. The fault was first observed in the building of the ecm subpackage, and came when configure was checking for the pow function. But I believe that any compilation that links to libm.so, and tries to use a function that already exists in /usr/lib/libm.so (like, for example, pow) will fail with the error:

undefined reference to symbol 'pow@@FBSD_1.0'.

The way cephes works is to create its own ${SAGE_ROOT}/local/lib/libm.so which contains all the C99 floating point functions that FreeBSD doesn't yet have. And then ${SAGE_ROOT}/local/lib/libm.so tells the linker to then look in /usr/lib/libm.so. But with the very recent versions of binutils, the linker ignores this latter request, because now the option --copy-dt-needed-entries defaults to --no-copy-dt-needed-entries.

How did I figure out that this was the error? It was pure serendipity. I just happened to look in the right place at the right time. I really only have a limited understanding of what is going on, and how linkers work. For example, when I read the man page for ld, and read what the option --copy-dt-needed-entries does, it was by no means obvious to me that this was actually the problem, rather it was a vague hope that this was the problem. So I tried it, and it worked. Yippee! And the only reason I thought that the option --copy-dt-needed-entries might be the issue was because I read http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/ld/NEWS?rev=1.131.2.1&content-type=text/plain&cvsroot=src&only_with_tag=binutils-binutils-2_23_2 and saw that this was one of the recent changes to ld.

comment:34 Changed 8 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:35 Changed 8 years ago by stephen

An issue has come up in sage-5.12.beta2, when trying to build sage using the port. The port adds options like -Wl,-rpath=lots-of-stuff to $(LDFLAGS). This is a problem for the ncurses-5.9 subpackage, because in its FreeBSD build it uses /usr/local/bin/ld to create a shared library, and then these options cause errors. The fix is very simple --- replace ld with cc. The attached patch fixes this problem. Nevertheless it is annoying to have to do this.

--- ncurses-5.9/src/configure.orig      2013-08-21 02:51:59.000000000 +0000
+++ ncurses-5.9/src/configure   2013-08-21 02:53:23.000000000 +0000
@@ -5719,7 +5719,7 @@
                cf_cv_shared_soname='`basename $@`'
        fi

-               MK_SHARED_LIB='${LD} -shared -Bshareable -soname=`basename $@` -o $@'
+               MK_SHARED_LIB='${CC} -shared -Bshareable -soname=`basename $@` -o $@'
                ;;
        netbsd*) #(vi
                CC_SHARED_OPTS="$CC_SHARED_OPTS -DPIC"

comment:36 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:37 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:38 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:39 Changed 4 years ago by dimpase

Please see a follow-up on #22679 (for FreeBSD 11.0).

I am trying to understand how the linking to Cephes-provided functions is meant to work (we probably only need cpow and clog from there, but still). The rest in fact looks OK - I am able to build a functioning version of Sage 7.6 (modulo the said issue, which causes a couple of hundred failing tests---no wonder).

See also https://groups.google.com/d/msg/sage-devel/C6nssytJHgY/D0dEJ2CyCQAJ

comment:40 Changed 3 years ago by jdemeyer

  • Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
  • Resolution set to duplicate
  • Status changed from new to closed

Closing as duplicate of #22679

Note: See TracTickets for help on using tickets.