Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#3018 scilab-4.1.2-1000

closed
5
2009-05-02
2007-11-17
Jack Howarth
No

Update package to latest 4.1.2 tarball and change build to gfortran from gcc42. Tested with the tests directory obtained from...

svn co --username anonymous --password Scilab http://svn.scilab.org/scilab/branches/BUILD_4/tests

using 'cd tests; make tests' in the build directory. Seems to be working well.

Discussion

1 2 > >> (Page 1 of 2)
  • Jack Howarth
    Jack Howarth
    2007-11-17

    scilab-4.1.2-1000 info file

     
    Attachments
  • Jack Howarth
    Jack Howarth
    2007-11-17

    Logged In: YES
    user_id=403009
    Originator: YES

    File Added: scilab.patch

     
  • Jack Howarth
    Jack Howarth
    2007-11-17

    • assigned_to: nobody --> jswhit
     
  • Jack Howarth
    Jack Howarth
    2007-11-17

    scilab-4.1.2-1000 patch file

     
    Attachments
  • Logged In: YES
    user_id=477035
    Originator: NO

    Please jack could you make a unified info file (varianted)
    for scilab and scilab-atlas ?
    Saves so much on maintenance ...

    Jean-Francois

     
  •  
    Attachments
  • Logged In: YES
    user_id=477035
    Originator: NO

    In absence of reply, I created one.
    Attaching it here, together with the corresponding
    patch file (only a minute difference there).

    One of the reasons such a unified file saves, is that
    in general fixes to one are also useful to the other...

    So please could you review this very carefully,
    (from the "non-atlas" point of view if you prefer _ I'll
    do then the same from the atlas point of view in the
    next few days).

    In particular, for the following 2 points :

    A) deps and builddeps: exactly correct?
    Especially xaw3d and libsablot
    I've not sufficient evidence; further I did not check that
    if scilab is built in the presence of all deps and builddeps
    of scilab-atlas, it still gives exactly the same build as
    when built on a "naked" fink installation.

    The following little script is often useful for this:

    # cat ~/bin/otool_deps
    #!/sw/bin/bash
    # `otool_deps <pkgs>` is the (possibly empty, alphabetically sorted, comma-separated) list of pkgs,
    # except for those in the argument list, followed by a newline, on which those in the argument list depend according to otool -L.
    dpkg -L $@|xargs file|fgrep 'Mach-O'|cut -f1 -d:|xargs otool -L 2>/dev/null|egrep -v ':$'|sort -u|sed -e 's,[[:space:]]\+,,' \ -e 's, .*,,'|xargs dpkg -S 2>/dev/null|cut -f1 -d:|sort -u|fgrep -vx "`tr ' ' '\n' <<<$*`"|xargs|sed -e 's; ;, ;g'

    (just removed here the aspects that needed fink's sed, fink's sort and grep (coreutils-default and grep pkgs)

    : all listed packages must be among the recursive deps, and the -dev packages correspoding to all listed packages must be among the builddeps.

    B) all little fixes: is each one still needed ? or just correct but not strictly indispensable ?
    or has become essentially incorrect because the source takes corresponding precautions ?

    Thanks a lot in advance !

    JF

    PS: After that, there will remain to find a mechanism for lpsolve-scilab to interact properly
    with this package (cf second point in DescPackaging of lpsolve-scilab).
    And I may want to put in a revision of atlas just before, splitting the dylib into its 4
    traditional parts _ since else that would require another rev-up for scilab-atlas.

    Even this tiny upgrade from 4.1.1 to 4.1.2 will require me to revise lpsolve-scilab :
    something has changed in scilab's build-system, and lpsolve-scilab no longer
    builds properly ..
    How I'd wish to get rid of that pkg .. !
    File Added: scilab.info

     
  • Logged In: YES
    user_id=353035
    Originator: NO

    I guess I'll take scilab over; I can run the dependency check.

     
    • assigned_to: jswhit --> alexkhansen
     
  • Logged In: YES
    user_id=60552
    Originator: NO

    I had a look at jfm's revision 1001. Some remarks:
    1. I got a couple of syntax errors from the variants stuff, so I changed this at a few places.
    2. The special compilation of dlamch.o and slamch.o is still necessary. This version takes care by default of dlamch.o by compiling it without optimization (I find -O2 -ffloat-store more elegant, because it leaves some optimization in place, and it displays the root of the problem). So we don't need to treat dlamch.o apart. But they forgot slamch.o, so we still need to treat it. I don't remember how the infinite loop for that one is triggered, but I remember that I introduced this part of the patch script after I got bitten by the bug. In more recent svn versions of scilab, they take care of both dlamch.o and slamch.o
    3. I did not try the atlas variant, but the standard variant compiles and runs OK, although I did not perform any special testing.
    4. The version I used is attached as revision 1002.

    File Added: scilab.info

     
1 2 > >> (Page 1 of 2)