Port of Scilab

[sylvestre@…]

Hello,

It would be nice to have Scilab available in MacPorts. It supports Mac OS X and I can provide help in the packaging.

Thanks Sylvestre

[raiyan.kabir@…]

I also need Scilab in MacPort. I hope it will be added in a future update.

[sylvestre@…]

Is there anyway to pay some consultants to see that happen ? (it is officially supported by upstream)

[petrus.hyvonen@…]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

It might be helpful to use Fink's package for Scilab as a reference when creating this portfile: ​http://fink.cvs.sourceforge.net/fink/dists/10.4/stable/main/finkinfo/sci/scilab.info?view=markup

[sylvestre@…]

The fink package is an (very) old version of Scilab.

By the way, as upstream, I tested the build of Scilab using MacPorts dependencies and it works fine out of the box (beside some java packages missing).

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

By the way, as upstream, I tested the build of Scilab using MacPorts dependencies and it works fine out of the box (beside some java packages missing).

Really? Did you do this manually? If so, which flags did you have to set to get it to work (if any)?

[sylvestre@…]

If manually=no using macports packaging format, yes.

Otherwise, besides the Java dependencies, the plain configure with normal options should work (just need --without-tk).

I am available for support.

[sylvestre@…]

FYI, Scilab has a GSoC proposal about a macports package if anyone is interested to package Scilab + its dependencies. ​http://wiki.scilab.org/GSoC_project_proposal

[cooljeanius (Eric Gallager)]

ok, I'm working on it. Atlas takes a while to build so I can't really start testing until after that finishes, seeing as it's a dependency...

[sylvestre@…]

For building, you could use refblas (I don't know how it is called in Macports). Slow at runtime but same ABI to Scilab will behave the same.

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

For building, you could use refblas (I don't know how it is called in Macports). Slow at runtime but same ABI to Scilab will behave the same.

Hm, port search refblas doesn't turn anything up... anyway you can see my progress so far at ​https://github.com/cooljeanius/LocalPorts/blob/master/science/scilab/Portfile

(I haven't managed to get it to build yet so that's why I'm not actually submitting it as an actual attachment yet... I think I know what I still need to do though.)

[sylvestre@…]

Sounds great.

Let me know if you want me to apply some of the changes in the configure.ac

Some comments:

• libgtkhtml, readline, Xaw3d, cairo, glitz, gtk2, libpng, pango, pixman, imake, tk and vte should not be necessary
• xmkmf is not used
• --with-gfortran is not necessary

You will likely have to package some java packages too...

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

Let me know if you want me to apply some of the changes in the configure.ac

Most of those are just to make autoscan happy; I haven't actually made any of the changes to the fink_prefix argument to work with MacPorts instead yet, and that was why I had started to edit it in the first place.

Some comments:

• libgtkhtml, readline, Xaw3d, cairo, glitz, gtk2, libpng, pango, pixman, imake, tk and vte should not be necessary

libgtkhtml, readline, Xaw3d, cairo, glitz, gtk2, libpng, pango, pixman, and vte were all listed as dependencies for the Fink package, so that's why I included them here. tk is because Fink has tcltk as a single package so included each of its pieces. As for imake, see my note about xmkmf below.

• xmkmf is not used

I included that because ./configure --help said it was an influential environment variable...

• --with-gfortran is not necessary

Again, I just took that from the Fink package..

[cooljeanius (Eric Gallager)]

OK, I worked past my previous problems; now I'm having some trouble getting the configure script to figure out how to link against lapack correctly...

[sylvestre@…]

What is the error message you are getting ?

[cooljeanius (Eric Gallager)]

I'll attach my latest config.log. How about you attach your config.log from when you said you managed to get Scilab to build against MacPorts libraries?

[cooljeanius (Eric Gallager)]

config.log from failure to find lapack

[sylvestre@…]

Looks like atlas has been compiled as static:

_ATL_ilaenv in liblapack.a(ATL_ilaenv.o)

I will send you the config.log tomorrow.

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

Looks like atlas has been compiled as static:

_ATL_ilaenv in liblapack.a(ATL_ilaenv.o)

That's just one of the libs that atlas installs:

gl00b05047:macportsscripts root# port contents atlas | grep lib
  /opt/local/lib/libatlas.a
  /opt/local/lib/libcblas.a
  /opt/local/lib/libf77blas.a
  /opt/local/lib/liblapack.a
  /opt/local/lib/libptcblas.a
  /opt/local/lib/libptf77blas.a
  /opt/local/lib/libsatlas.dylib
  /opt/local/lib/libtatlas.dylib

Should I be telling it to link against a different one of them?

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

I will send you the config.log tomorrow.

So... tomorrow has come and passed...

[sylvestre@…]

Sorry, I haven't receive it yet (I did it on a computer friend)

[sylvestre@…]

Working config.log

[sylvestre@…]

Sorry about the delay. The config.2.log​ should have most of the information.

[cooljeanius (Eric Gallager)]

hm, I'm still having problems with atlas... someone should cc vince@… on this, seeing as he's the maintainer for atlas.

[sylvestre@…]

@egall any news about the atlas issue ?

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

@egall any news about the atlas issue ?

Well it turns out there are actually a lot of atlas issues:

​https://trac.macports.org/report/16?PORT=atlas

(some of them are preventing atlas from building for me currently)

[cooljeanius (Eric Gallager)]

ok, atlas issues are mostly worked out now, although now I have to update the portfile to 5.4.1... doing so broke my patch for configure.ac, so I'm commenting that out for now...

[cooljeanius (Eric Gallager)]

rejects from failed patch after updating 5.4.0 to 5.4.1

[cooljeanius (Eric Gallager)]

now arpack has some issues that would probably have to be worked out first: #39365

[mojca (Mojca Miklavec)]

Just a note: if I compile the failing program from your config.log:

/* Define cheev_ to an innocuous variant, in case <limits.h> declares cheev_.
   For example, HP-UX 11i <limits.h> declares gettimeofday.  */
#define cheev_ innocuous_cheev_

/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char cheev_ (); below.
    Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
    <limits.h> exists even on freestanding compilers.  */

#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif

#undef cheev_

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char cheev_ ();
/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined __stub_cheev_ || defined __stub___cheev_
choke me
#endif

int
main ()
{
return cheev_ ();
  ;
  return 0;
}

then

clang config.log -llapack

works (it takes the library from /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib), but

clang conftest.c -llapack -L/opt/local/lib

fails. See also #40317.

[mojca (Mojca Miklavec)]

Cc Me!

[cooljeanius (Eric Gallager)]

Replying to mojca@…:

then

clang config.log -llapack

works (it takes the library from /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib), but

clang conftest.c -llapack -L/opt/local/lib

fails. See also #40317.

Wait I don't get why this happens... is the file you're compiling in each case (config.log and conftest.c) actually the same in each case, just with different names?

[mojca (Mojca Miklavec)]

I'm sorry. The first line should have been

clang conftest.c -llapack

of course.

[mojca (Mojca Miklavec)]

> clang conftest.c -llapack
# OK

> clang conftest.c -llapack -L/opt/local/lib
Undefined symbols for architecture x86_64:
  "_ATL_cGetNB", referenced from:
      _ATL_ilaenv in liblapack.a(ATL_ilaenv.o)
  "_ATL_dGetNB", referenced from:
      _ATL_ilaenv in liblapack.a(ATL_ilaenv.o)
  "_ATL_sGetNB", referenced from:
      _ATL_ilaenv in liblapack.a(ATL_ilaenv.o)
  "_ATL_sscal", referenced from:
      _ATL_clacgv in liblapack.a(ATL_clacgv.o)
  "_ATL_zGetNB", referenced from:
      _ATL_ilaenv in liblapack.a(ATL_ilaenv.o)
  "__gfortran_compare_string", referenced from:
      _ilaenv_ in liblapack.a(ilaenv.o)
  "_caxpy_", referenced from:
      _chetd2_ in liblapack.a(chetd2.o)
      _clatrd_ in liblapack.a(clatrd.o)
  "_cblas_ccopy", referenced from:
      _ATL_clarfb in liblapack.a(ATL_clarfb.o)
  "_cblas_cdotc_sub", referenced from:
      _ATL_clarftFC in liblapack.a(ATL_clarft.o)
      _ATL_clarftBC in liblapack.a(ATL_clarft.o)
      _ATL_clarftFR in liblapack.a(ATL_clarft.o)
      _ATL_clarftBR in liblapack.a(ATL_clarft.o)
  "_cblas_cdotu_sub", referenced from:
      _ATL_clarftFC in liblapack.a(ATL_clarft.o)
      _ATL_clarftBC in liblapack.a(ATL_clarft.o)
      _ATL_clarftFR in liblapack.a(ATL_clarft.o)
      _ATL_clarftBR in liblapack.a(ATL_clarft.o)
  "_cblas_cgemm", referenced from:
      _ATL_clarfb in liblapack.a(ATL_clarfb.o)
      _ATL_clarft_blockFC in liblapack.a(ATL_clarft.o)
      _ATL_clarft_blockFR in liblapack.a(ATL_clarft.o)
      _ATL_clarft_blockBC in liblapack.a(ATL_clarft.o)
      _ATL_clarft_blockBR in liblapack.a(ATL_clarft.o)
  "_cblas_ctrmm", referenced from:
      _ATL_clarfb in liblapack.a(ATL_clarfb.o)
      _ATL_clarft_blockFC in liblapack.a(ATL_clarft.o)
      _ATL_clarft_blockFR in liblapack.a(ATL_clarft.o)
      _ATL_clarft_blockBC in liblapack.a(ATL_clarft.o)
      _ATL_clarft_blockBR in liblapack.a(ATL_clarft.o)
  "_cdotc_", referenced from:
      _chetd2_ in liblapack.a(chetd2.o)
      _clatrd_ in liblapack.a(clatrd.o)
  "_cgemv_", referenced from:
      _clatrd_ in liblapack.a(clatrd.o)
      _clarf_ in liblapack.a(clarf.o)
  "_cgerc_", referenced from:
      _clarf_ in liblapack.a(clarf.o)
  "_chemv_", referenced from:
      _chetd2_ in liblapack.a(chetd2.o)
      _clatrd_ in liblapack.a(clatrd.o)
  "_cher2_", referenced from:
      _chetd2_ in liblapack.a(chetd2.o)
  "_cher2k_", referenced from:
      _chetrd_ in liblapack.a(chetrd.o)
  "_cscal_", referenced from:
      _clatrd_ in liblapack.a(clatrd.o)
      _clarfg_ in liblapack.a(clarfg.o)
      _cung2l_ in liblapack.a(cung2l.o)
      _cung2r_ in liblapack.a(cung2r.o)
  "_csscal_", referenced from:
      _clarfg_ in liblapack.a(clarfg.o)
  "_cswap_", referenced from:
      _csteqr_ in liblapack.a(csteqr.o)
  "_lsame_", referenced from:
      _cheev_ in liblapack.a(cheev.o)
      _chetrd_ in liblapack.a(chetrd.o)
      _clanhe_ in liblapack.a(clanhe.o)
      _clascl_ in liblapack.a(clascl.o)
      _csteqr_ in liblapack.a(csteqr.o)
      _cungtr_ in liblapack.a(cungtr.o)
      _ilaenv_ in liblapack.a(ilaenv.o)
      ...
  "_scnrm2_", referenced from:
      _clarfg_ in liblapack.a(clarfg.o)
  "_sscal_", referenced from:
      _cheev_ in liblapack.a(cheev.o)
  "_xerbla_", referenced from:
      _cheev_ in liblapack.a(cheev.o)
      _chetrd_ in liblapack.a(chetrd.o)
      _clascl_ in liblapack.a(clascl.o)
      _csteqr_ in liblapack.a(csteqr.o)
      _cungtr_ in liblapack.a(cungtr.o)
      _ssterf_ in liblapack.a(ssterf.o)
      _chetd2_ in liblapack.a(chetd2.o)
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[cooljeanius (Eric Gallager)]

Well I can't exactly go removing -L${prefix}/lib from the configure.ldflags... ld needs to look in there for other things...

[mojca (Mojca Miklavec)]

All I wanted to say is that there is something suspicious going on with atlas.

[sylvestre@…]

Replying to mojca@…:

All I wanted to say is that there is something suspicious going on with atlas.

Yes, looks like the liblapack library has not been compiled with an explicit -lblas.

Adding -lblas to the command

clang conftest.c -llapack

should fix the problem.

[cooljeanius (Eric Gallager)]

Yay, I finally have a working portfile! Gosh, Scilab contains a lot of stuff:

Local-Admins-MacBook-Pro:~ root# port contents scilab | wc -l
   12536

Anyway, I'll attach the portfile in a little bit...

[sylvestre@…]

Scilab is indeed a big baby! Well done for the portfile! I am looking forward to it.

[sylvestre@…]

egall: can you share the portfile ? thanks

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

egall: can you share the portfile ? thanks

I'm actually still working on it, there are a few more things I want to add support for...

Edit: also I've found out that Fink is working on an update to their Scilab package, so I'm trying to incorporate some of the changes they're making: ​http://cvs.snaggledworks.com/viewvc.cgi/fink/3rdparty/main/finkinfo/sci/scilab.info?view=markup

[sylvestre@…]

Sure. It is just that I could help :)

[cooljeanius (Eric Gallager)]

Portfile for Scilab

[cooljeanius (Eric Gallager)]

zip of ${filespath} directory (to be placed next to Portfile)

[cooljeanius (Eric Gallager)]

Replying to sylvestre@…:

Sure. It is just that I could help :)

OK, I've attached the latest version... Even though I'm now copying the java stuff into the build directory, I still have to end up turning it off with some configure flags though, because otherwise I still end up running into errors... Even though the entire thing builds and works with java turned off, I'll probably want to get it turned on before it would be ready to commit to trunk...

[locober@…]

Cc Me!

[petrrr]

Cc Me!

[Schamschula (Marius Schamschula)]

Cc Me!