[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #50463] gsvd implementation uses functions rem

From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #50463] gsvd implementation uses functions removed from lapack >= 3.6.0
Date: Sat, 23 Dec 2017 09:12:38 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0

Follow-up Comment #19, bug #50463 (project octave):

With a cross build of the development branch (I don't remember which hg id of
mxe-octave that is from, but it was built on 16 Dec 2017), I see:

>> check_lib_fcn ("liblapack", "dggsvd_")
ans = 1
>> check_lib_fcn ("liblapack", "dggsvd3_")
ans = 1

On another note: the "dynamic_library" class (in oct-shlib.cc) differentiates
between four different mechanism to load shared libraries:

  dynamic_library::dynlib_rep *
  dynamic_library::dynlib_rep::new_instance (const std::string& f)
#if defined (HAVE_DLOPEN_API)
    return new octave_dlopen_shlib (f);
#elif defined (HAVE_SHL_LOAD_API)
    return new octave_shl_load_shlib (f);
#elif defined (HAVE_LOADLIBRARY_API)
    return new octave_w32_shlib (f);
#elif defined (HAVE_DYLD_API)
    return new octave_dyld_shlib (f);
      ("support for dynamically loaded libraries was unavailable or disabled
when liboctave was built");

Is it save to unconditionally use the dlsym magic on Linux and Mac, and the
"dynamic_library" class on Windows only?

OT: Does MXE Octave insert its hg id somewhere into the build? A text file
somewhere in the packed folders would probably be enough to keep track of it.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]