I have a Cython extension which I've compiled on Ubuntu 14 and uploaded as an Anaconda package. I'm trying to install the package on another machine which is running Scientific Linux (6?) which ships with an older version of glibc. When I try to import the module I get an error that looks (something like) this:
./myprogram: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./myprogram)
When I say "something like" - the "myprogram" is actually the .so name of the extension.
From what I understand this error is because I have a newer version of glibc on the build system which has an updated version of the memcpy function.
This page has a good description of the problem, and some rather impractical solutions: http://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
There is also a much simpler answer proposed here: How can I link to a specific glibc version?
My question is: how to I apply this solution to my Cython extension? Assuming the __asm__ solution works (as given in the second link) what's the best way to get it into the C generated by Cython?
Also, more generally, how to other modules avoid this issue in the first place? For example, I installed and ran a pre-built copy of numpy without any issues.
This turned out to be quite simple.
Create the following header, glibc_fix.h:
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5")
Then include it by using CFLAGS="-include glibc_fix.h". This can be set as an environment variable, or defined in setup.py.
Additionally, it turns out numpy doesn't do anything special in this regard. if I compile it myself it links with the newer version on my system.
Related
I am working on a fully cython compiled python package, using setuptools and some reStructured Text docstrings to generate the pdf documentation using sphinx-autodoc with good success.
The docstrings are not displayed when loading the package in Jupyter Notebooks (using Pylance language server in VSCode). I did not test but suspect that the issue exists in other IDEs or frontends either. Switching to e.g. Jedi as a language server in VSCode did not help.
Using the help(...) command on the routines/classes yields the expected docstring, so the issue does not seem to be with the cython compilation.
There are quite a few issues about formatting issues popping up when searching for Docstrings and Pylance, the issue never seems to be that they simply can not be retrieved.
Since sphinx (autodoc) does not throw any errors and generates a full-package encompassing documentation set fine, this seems a lot like a problem with the language servers to me.
However, I suspect that there may be any compiler directive or setuptools option that I am unaware of that could help - but I do not know about these.
I do have
compiler_directives={'embedsignature': True}
in the setup.py and since the docstrings do show up when using help(..), I do not think this is an issue.
I have also added
import Cython.Compiler.Options
Cython.Compiler.Options.docstrings = True
even though that is indicated as being the default, and it did not change the behavior at all.
Scavenging through the options of Pylance in VSCode was unfruitful, too - I did not expect much there anyways, since obviously the display of the docstrings does work for plenty (all?) other packages that I looked at. Everything is on defaults.
I have been working on a github project from here:
https://github.com/jiacheng-xu/DiscoBERT
According to the authors, it requires Allennlp 0.9.0. I created a virtual environment using pip and tried installing 0.9, but it gave an error. So, I tried Allennlp 1.2 which installed fine,
but I am getting errors in the two following lines:
from allennlp.commands.fine_tune import fine_tune_model_from_file_paths
from allennlp.modules.token_embedders.bert_token_embedder import PretrainedBertModel, PretrainedBertEmbedder
It seems, in the 1.2 version at least, there is no fine_tune and bert_token_embedder module. Is there a quick way to get past these errors?
From https://github.com/allenai/allennlp/issues/4849:
We removed the file_tune command. You can now create your model with the from_archive() constructor (either with code, or from the config file), and train that way.
bert_token_embedder has also gone away. We unified the support for huggingface models in the pretrained_transformer_* classes. So there is now a pretrained_transformer_tokenizer, pretrained_transformer_indexer and a pretrained_transformer_embedder. Before we had several slightly different ways of doing the same thing, and that seemed dangerously confusing.
Why did installing the old version fail though? There is no reason old versions wouldn't work.
I’m having a problem with printing figures in octave when the figure’s visibility is set to false. For example, the following code produces a “panic: segmentation fault” in Octave version 4.2.2:
t = 1:10;
fh = figure(“visible”, false);
plot(t,sin(t))
print(“fig.png”)
If I run the above code in Octave version 5.2.0, there is no problem. Is this a bug that was fixed in the Octave 5 update? If so, is there a workaround that I can use for Octave 4? I would prefer to use Octave 4 if possible.
Other notes:
I am running this in Ubuntu 16.04.6 LTS and I installed octave 4 using apt.
The answer to your question is, yes. Here is the relevant line from the v5.1.0 NEWS:
Dependencies:
The GUI requires Qt libraries. The minimum Qt4 version supported is Qt4.8. Qt5 of any version is preferred.
The OSMesa library is no longer used. To print invisible figures when using OpenGL graphics, the Qt QOFFSCREENSURFACE feature must be available and you must use the qt graphics toolkit.
Apparently the now deprecated OSMESA dependency and the printing of invisible figures was a long-standing pain-in-the-butt. Maybe you'll have some luck going through bug comments (e.g. someone says that if you make it visible at least once, it may be possible to print).
But as people have said in the comments, the best thing to do would be to upgrade your octave version, and recompile your mexfiles for the new version.
I am trying to run a piece of code that includes "itkScalarImageTextureCalculator.h". However, cmake cannot find this reference, and I can't seem to find it manually neighter. I've looked for it in
Modules/Numerics/Statistics/include
Modules/Compatibility/V3Compatibility/include
Modules/Compatibility/Deprecated/include
but i can't find it anywhere. A search in the itk folder also returns no results. Was this library deleted/renamed/moved somewhere else? Or maybe there is some kind of problem with my itk installation? I have successfuly used other libraries, and I only have itk installed (I mean I don't have vtk, tcl etc).
It has been renamed itkScalarImageToTextureFeaturesFilter (probably in ITK 4.0). You can see this conversion listed in the table here: http://itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Migration_Users_Guide
I'm trying to translating the MySql C connector 6.02 headers to D, but I get some weird crashes.
My guess is I've made some mistakes on translating the structs or function (I'm not very good at C).
I used implib /system on the libmysql.dll to create a lib file.
I couldn't get htod.exe to work. Using -hs (include system files) complained it couldn't find system files.
Coffimplib.exe didn't have an option to prepend _ to exported internal names.
I couldn't find a free version of coff2omf.
mysql.d is the wrapper. I've included the C definition before each wrapped definition to easier spot bugs. The file includes the mysql dll and converted libfile too.
When compiling mytest_fails.d it crashes. mytest_works.d only has an assert, and this makes it work.. Compiling mytest_works with -release makes it crash too.
I've been using dmd 2.051
Download mytest.zip from share1t.com
Update: I've also asked some question regarding this on the D.learn newsgroup, but I don't think anyone has gone through the code.
C Const
Compiler extensions
Connot get htod.exe to work
The weird crashes
stdcall is a Windows function calling convention (very different from the C calling convention). HTOD failed to mark several functions with extern(Windows). This is normal, since HTOD isn't equipped to handle macros (STDCALL is defined as a macro, I can see that from the leftover comments in msyql.d).
Here's an updated mysql.d file:
http://dl.dropbox.com/u/9218759/mysql.d
Now, you need the proper import library in OMF format. I'd generally advise that you do not use implib for this. I've had several problems with it and others have reported having problems using it. Using coffimplib is the way to go. But first, you will need a COFF import library.
If you need it, the Mysql release with the COFF import library can be downloaded from here: http://dev.mysql.com/downloads/mirror.php?id=377977#mirrors (Libraries in DLL form marked for Visual Studio usually come with a COFF import library).
But I'm providing you the translated COFF import library in OMF format here: http://dl.dropbox.com/u/9218759/libmysql.lib
I've tried both of your test cases and they both seem to work fine now. In case of problems, try to check the translated header file again (mysql.d), it's possible that I might have missed to specify all the calling conventions properly.