SUNDIALS solvers interface into Matlab.

Error using mex

MEX cannot find library 'sundials_cvode', specified with the -l option.

MEX searched for a file with one of the following names:

libsundials_cvode.lib

sundials_cvode.lib

Verify the library name is correct. If the library is not

on the existing path, specify the path with the -L option.

I am getting the above error while executing the mex. the library name is "libsundials_cvode.a". Do I need to change the extension to ".lib" or the error is something else.

I am trying to create the sundials interface into MATLAB. I know the latest versions of MATALAB have sundials configured in it. Just doing it for a learning.

[dpb]

".a" is the default extension used for output library object files; it appears the make file you're using is not defining or renaming that library file to use the .lib extension instead.

Either fix the earlier place where that is to name the built .lib file as is expected or alternatively, just patch the library -l name to match what you do have.

Without any knowledge of from where you got the package you're trying to build, folks here are pretty much at a loss as to what you may have done incorrectly...or able to see what might actually be wrong in the make file you're using

[Ajinkya]

here I have the file installed. what should I do then?

[dpb]

My old eyes can't read that and can't do anything with an image, anyways...need to see the actual make file; probably better to link to the source of what you're trying to build so folks have some klew as to what you actually started with...maybe it's bum.

As noted, the simplest fix, presuming the lib file was actually made correctly (which may be a big assumption, we can't tell) is to simply rename the .a lib file to match the link lib name--of course, that means starting at the link step and not rebuilding the whole thing which would simply recreate the .a version.

As noted earlier, this indicates something is broken in the make file but we can't see it from here...whoever created/posted it would be the one/place to turn to.

Answer 1

[Walter Roberson]

You appear to be using MS Windows. MS Windows does not use the .a file extension -- the .a file extension is for statically linked libraries on Linux and MacOS.

In order to link .dll files, the executable must be linked against a .lib file

If all you have are .dll files and .a files then you cannot successfully link in Windows -- the .a will be ignored in Windows and the .dll need .lib

[Ajinkya]

So do I convert the extension of ".a" to ".lib" ?

Will that help

[Walter Roberson]

As an experiment, try copying libsundials_cvode.a to libsundials_cvode.lib

[Ajinkya]

Okay, I will try this one.

[dpb]

@Ajinkya, why do you continue to hide the make file from us or at least point to from whence it came? Then, somebody could make the changes needed to solve the problem...if, as Walter surmises this is for non-Windows, there's a pretty good chance the includes it references also are not for Windows besides the naming conventions chosen.

[Ajinkya]

Please tell me what should I share?

I am downloading the build files using MSYS terminal.

[dpb]

Oh. I was presuming running an nmake file locally. I "know nuthink!" about MSYS and how it manages things.

What I was expecting and therefore looking for was the actual make command file that has the rule for compiling the source into object files -- in there is the naming convention that results in the lib file with the dot-a extension; a leftover from Linux-like systems.

That still implies to me there's something not quite right in trying to build this for Windows; if it were for native Windows, that rule should know enough to name the file with the proper extension.

But, at this point, it's over my head; all I can do is echo my previous suggestion that is also Walter's idea to try to rename the file and see if it will remain left over from the previous build and the linker will then find that one. If, like many build tools, this one cleans out the working directories of everything it's going to rebuild, then that renamed file may also end up being deleted before the build begins and it still will only exist as the .a version.

Running this way also means you can't stop in the middle to rename the file and then pick up only at the link step if the above fails...

[Ajinkya]

Yes, I changed the extension to ".lib" and now its not giving the above error.

Bad news !! It gave me a new error now.

-----------------------------------------------------------------------

Error using mex

sundials_interface.c

C:/msys64/home/z0052r2r/sundials/include/sundials/sundials_config.h(59): fatal error C1021: invalid preprocessor command 'cmakedefine'

[dpb]

Yeah, I think you're running into the issue of it running into gcc compiler syntax but it's MSVC that is getting called here....C1021 is a MSVC error; MS VisualC preprocessor directives must begin with a # character which the source file doesn't contain because it is written for gcc.

I've no klew with MSYS how you control the toolset being used; I would have thought since it is connected that it would be already set up when installed, but as noted, I have never even tried to use it, what more have any actual knowledge about it.

You'll need an expert there to have any hope, methinks...

[Ajinkya]

Could you please tag any expert person that you know in the comments?

[dpb]

Impolite and improper use of tags to use contributors...and I know nobody in the area, anyways. One would suppose there are support groups associated with the MSYS organization.

Somewhere in the bowels of that downloaded folder C:/msys64/home/z0052r2r/sundials will be the actual make file that is being run; it would be interesting to look into it and turn on a verbose mode flag for compiler switches to see what it shows... for gcc that would be "-v", it's been so long since used MS VC I don't recall which it is there.

I had to rebuild the machine a while back and haven't yet gotten around to reinstalling the compiler(s) so don't have anything to play with here at the moment...