Name 'cbclib' is not defined

[erelsgl]

Describe the bug

I cannot solve even a very simple program, because the system claims that cbclib is not defined:

Traceback (most recent call last):
  File "test_mip.py", line 2, in <module>
    m = Model("test", solver_name=CBC)
  File "local-packages\Python310\site-packages\mip\model.py", line 87, in __init__
    import mip.cbc
  File "local-packages\Python310\site-packages\mip\cbc.py", line 603, in <module>
    Osi_getNumCols = cbclib.Osi_getNumCols
NameError: name 'cbclib' is not defined

To Reproduce

from mip import Model, CBC
m = Model("test", solver_name=CBC)

Expected behavior No error.

Desktop (please complete the following information):

• Windows 11 22H2
• Python version: 3.10.10
• Python-MIP version (we recommend you to test with the latest version): 1.15.0 (also exists in 1.14.0)

[sebheger]

@erelsgl Is it a special problem if version 1.15.0? Because you reported #337 which looks like you get a working version 1.14.0?

[erelsgl]

I did it in a different computer, where I have version 1.14.0 and Python 3.10.2. I do not know if the reason is related to MIP version, Python version, or something else.

[rschwarz]

The error NameError: name 'cbclib' is not defined is a consequence of the ffi.dlopen(libfile) not working, right? This can have different reasons (file not found, some dependency missing, library incompatible to architecture), so it would be great to have a more specific error message here, but I don't know whether cffi can supply that.

[erelsgl]

I verified that the problem exists also in version 1.14.0.

[kotaishr-ie]

I guess this is caused by the fact that python-mip 1.15 and CBC 2.10.8 are not compatible.

While python-mip 1.15 requires libCbc.dylib to have Osi_getIntegerTolerance, Cbc 2.10.8 and other recent releases doesn't seem to include this in the interface. However, in the master branch, Osi_getIntegerTolerance is included in the interface.

I guess that we have to use Cbc@master due to compatibility constraints for now.

[DRMacIver]

I think there are two slightly distinct things here:

1. Compatibility with different CbC problems (genuine problem, solution is currently to use master as you say)
2. The error you get when you run into (1) is very confusing, as the code designed to handle this path doesn't work correctly.

The cbc module actually goes to some work to check for such an error and set a has_cbc flag if it fails. The problem is that code further down the file then goes on to unconditionally use cbclib.

It seems like this means the error handling here ends up the worst of both worlds and either all of the code in this module other than the initial loading should exist in a has_cbc block, or the error from loading cbclib should just be left to propagate.

[erelsgl]

I still have the same issue, which prevents me from using MIP on Windows 11. Is it possible, at least, to add some work-around to the installation docs?

[pabloazurduy]

hey, has anyone found a workaround for this issue? 🙏 thaaanks

[pabloazurduy]

hey, I managed to find a workaround on a M1 pro MacBook: create a conda env using x86 arch

CONDA_SUBDIR=osx-64 conda create -n myenvmip python=3.10.10 mip 
conda activate myenvmip

done :), probably is not efficient but, works

[OverLucker]

I think my problem is related to this topic

I use M1 pro MacBook. Stack trace:

An error occurred while loading the CBC library:         cannot load library '/some/path/lib/python3.11/site-packages/mip/libraries/cbc-c-darwin-x86-64.dylib': dlopen(/some/path/lib/python3.11/site-packages/mip/libraries/cbc-c-darwin-x86-64.dylib, 0x0002): tried: '/opt/homebrew/opt/[email protected]/lib//cbc-c-darwin-x86-64.dylib' (no such file), /some/path/lib/python3.11/site-packages/mip/libraries/cbc-c-darwin-x86-64.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/some/path/lib/python3.11/site-packages/mip/libraries/cbc-c-darwin-x86-64.dylib' (no such file), '/some/path/lib/python3.11/site-packages/mip/libraries/cbc-c-darwin-x86-64.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')).  Additionally, ctypes.util.find_library() did not manage to locate a library called '/some/path/lib/python3.11/site-packages/mip/libraries/cbc-c-darwin-x86-64.dylib'

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/some/path/lib/python3.11/site-packages/mip/model.py", line 98, in __init__
    import mip.cbc
  File "/some/path/lib/python3.11/site-packages/mip/cbc.py", line 603, in <module>
    Osi_getNumCols = cbclib.Osi_getNumCols
                     ^^^^^^
NameError: name 'cbclib' is not defined

Key problem is the warning message at the start: mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')),

Look at lib/python3.11/site-packages/mip/libraries directory.

There is no macos m1 distribution.

Compile it manually via coinbrew. Swap cbc-c-darwin-x86-64.dylib with own compiled file.

It works! 🎆

I think you should add precompiled binary for macos m1.

[tuliotoffolo]

Python-MIP’s latest release candidate version (1.16rc0) includes binaries compatible with M1/M2/M3 processors. To install it, you can use pip:

• pip3 install mip==1.16rc0

[MarcelloCeresini]

For me it's not working. I have a M2 and I ran pip3 install mip==1.16rc0 but still I got "name 'cbclib' is not defined".

Reason: did not manage to locate a library called '.../env/lib/python3.12/site-packages/mip/libraries/cbc-c-darwin-arm64.dylib'

[nhuet]

The fix pip3 install mip==1.16rc0 was working before on macos-latest github runners, but not anymore since the release of the new image: https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20240514.3 Have you an idea what has changed in the runner (see above link) that could explained this?

[erelsgl]

I too updated mip to 1.16rc0, and I still get the same error: "NameError: name 'cbclib' is not defined". I am on Windows 11 on an HP machine.

[MaxWinterstein]

When looking at the error message in detail I found it is linked against libgfortran.5.dylib. For me brew install gcc brought it to my machine and fixed the 'cbclib' is not defined issue. The error message is kinda misleading.

My colleague still had issues, turns out he had some homebrew installation migrated from his old Intel to his new M2 MacBook. Therefore brew was installed to /usr/local instead of /opt/homebrew, which is the correct location for Apple Silicon installations. Reinstalling brew and installing gcc fixed it for him, too.

[erelsgl]

I think there are two slightly distinct things here:

1. Compatibility with different CbC problems (genuine problem, solution is currently to use master as you say)

2. The error you get when you run into (1) is very confusing, as the code designed to handle this path doesn't work correctly.

I agree. Can someone please fix problem number 2? This way, we will get an informative error message, and will be able to proceed in fixing the error.

[erelsgl]

OK, I found a workaround: upgrade Python from 3.10 to 3.11. It worked for me. (Upgrading to 3.12 didn't work though - I got an "illegal access" error from Windows).