Closed erendn closed 11 months ago
Any ideas @proppy?
0.27.4 is very old. Do you have change to update to 0.27.13 and try again?
Nicely prepared testcase BTW :)
A quick check with 0.28.3 on Ubuntu 22.04 (package from www.klayout.org) shows no crash and no DRC violations:
$ klayout -b -r freepdk45.lydrc -rd input=sram_bank.gds -rd topcell=sram_bank -rd output=sram_bank.drc.report
...
Writing report database: /home/matthias/klayout/testdata/issue-1263/sram_bank.drc.report ..
Total elapsed: 3.650s Memory: 1114.00M
You can also try version 0.28.3, but the 0.28 branch is still annealing.
Matthias
conda-eda conda channel: https://anaconda.org/LiteX-Hub/klayout/files should have more recent version than 0.27, see https://anaconda.org/LiteX-Hub/klayout/files
@erendn any reason you're staying on 0.27?
@klayoutmatthias - When I try 0.28.3, I get this error. It seems like there is an issue with ruby. This is the setup I used for 0.28.3.
@proppy - We were using 0.27.4 in the Docker image of OpenRAM. @mguthaus might better know why.
I built other tools with python 3.8 and conda-eda/klayout is built with python 3.7. So there is a version conflict when I try to install conda-eda/klayout along with other tools. To try this specific test case with conda-eda/klayout, I installed miniconda with python 3.7, and the error I got is below. I also built klayout with my recipe using python 3.7 and klayout 0.28.3, and I got the same error as above.
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libcif.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libdxf.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libgds2.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/liblefdef.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libmag.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libnet_tracer.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/liboasis.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libpcb.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libbool_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libcif_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libcommon_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libd25_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libdiff_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libdxf_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libgds2_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libimport_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/liblefdef_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libmag_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libnet_tracer_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/liboasis_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libpcb_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libxor_ui.so
ERROR: In freepdk45.lydrc: 'source': Stream has unknown format: sram_bank.gds in Layout::read
ERROR: 'source': Stream has unknown format: sram_bank.gds in Layout::read in Executable::execute
freepdk45.lydrc:13:in `execute'
:/built-in-macros/drc_interpreters.lym:27:in `instance_eval'
:/built-in-macros/drc_interpreters.lym:27:in `execute'
@erendn can you comment in https://github.com/hdl/conda-eda/issues/260 about this affecting you for klayout, that way we can focus the discussion here on klayout and discuss the packaging aspect over there.
We are using 27.4 because it was the latest when I debugged using it. It just hasn't been bumped since then.
I managed to find one of the issues. $KLAYOUT_PATH was pointing to another klayout installation, and klayout failed to load those plugins. Now, I'm getting the following error (klayout 0.28.3):
ERROR: In freepdk45.lydrc: 'source': Stream has unknown format: sram_bank.gds in Layout::read
ERROR: 'source': Stream has unknown format: sram_bank.gds in Layout::read in Executable::execute
freepdk45.lydrc:13:in `execute'
:/built-in-macros/drc_interpreters.lym:27:in `instance_eval'
:/built-in-macros/drc_interpreters.lym:27:in `execute'
I fixed this issue by setting $KLAYOUT_PATH to miniconda/lib/klayout
.
@proppy - I can reproduce the same issue with conda-eda/klayout if $KLAYOUT_PATH is unset.
@erendn, thanks! filed https://github.com/hdl/conda-eda/issues/281
I'm not sure - is this problem fixed?
The stream format error usually means that the stream reader plugins cannot be loaded. In that case, the GDS stream format reader is not available.
The way these plugins are loaded is that KLayout will look up a folder called "db_plugins" next to the "db" library. In my case that is
db_plugins/...
libklayout_db.so -> libklayout_db.so.0.28.3
libklayout_db.so.0 -> libklayout_db.so.0.28.3
libklayout_db.so.0.28 -> libklayout_db.so.0.28.3
libklayout_db.so.0.28.3
"db_plugins" contains .so files with the stream readers:
libcif.so -> libcif.so.0.28.3
libcif.so.0 -> libcif.so.0.28.3
libcif.so.0.28 -> libcif.so.0.28.3
libcif.so.0.28.3
libdxf.so -> libdxf.so.0.28.3
libdxf.so.0 -> libdxf.so.0.28.3
libdxf.so.0.28 -> libdxf.so.0.28.3
libdxf.so.0.28.3
libgds2.so -> libgds2.so.0.28.3
libgds2.so.0 -> libgds2.so.0.28.3
libgds2.so.0.28 -> libgds2.so.0.28.3
libgds2.so.0.28.3
...
$KLAYOUT_PATH should not be involved here.
So now, if "db_plugins" sits somewhere else or there is a problem loading these Libraries, then GDS is not available (among all other formats).
If the .so files are there and cannot be loaded you can try:
$ klayout -d 31
prints:
...
Loading plugin: /usr/lib/klayout/db_plugins/libcif.so
Loading plugin: /usr/lib/klayout/db_plugins/libdxf.so
Loading plugin: /usr/lib/klayout/db_plugins/libgds2.so
Loading plugin: /usr/lib/klayout/db_plugins/liblefdef.so
Loading plugin: /usr/lib/klayout/db_plugins/libmag.so
Loading plugin: /usr/lib/klayout/db_plugins/libmebes.so
Loading plugin: /usr/lib/klayout/db_plugins/libnet_tracer.so
Loading plugin: /usr/lib/klayout/db_plugins/liboasis.so
Loading plugin: /usr/lib/klayout/db_plugins/libpcb.so
...
or debug the problem mit LD_DEBUG:
$ LD_DEBUG=files klayout -d 31
prints in my case:
...
1356582: calling init: /usr/lib/klayout/lay_plugins/libgds2_ui.so
1356582:
1356582: opening file=/usr/lib/klayout/lay_plugins/libgds2_ui.so [0]; direct_opencount=1
1356582:
1356582: /usr/lib/klayout/lay_plugins/libgds2_ui.so: error: symbol lookup error: undefined symbol: klp_init (fatal)
Loaded plugin '/usr/lib/klayout/lay_plugins/libgds2_ui.so'
...
The message "error: symbol lookup error: undefined symbol: klp_init (fatal)" is OK - KLayout tries to find a custom initialization entry point which this plugin does not have. Other errors may give you some hint about the solution for your problem.
Matthias
The problem was with the conda environment. KLayout's db_plugins
were installed in miniconda/lib/klayout/db_plugins
while the other .so
files were installed in miniconda/lib
. KLayout searched in miniconda/lib/db_plugins
but not miniconda/lib/klayout/db_plugins/
.
It seems like the error isn't fixed yet :/
We have many unit tests running in parallel and some of them fail randomly. When I inspect the output, I can see that they give errors similar to the ones above. So it seems like KLayout fails to load plugins randomly. But when I manually run the scripts, KLayout can load the plugins without any error. I'm still unsure if something is wrong with the environment or the KLayout installation.
Also, running klayout -d 31
gives:
Warning: could not connect to display
Info: Could not load the Qt platform plugin "xcb" in "" even though it was found.
Fatal: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, webgl, xcb.
That error comes from Qt. I assume it means something similar - the shared objects can be found, but not loaded. Usually because some references are not found.
I found this thread about a similar issue, but I don't know if that helps: https://stackoverflow.com/questions/57362015/how-to-fix-could-not-load-the-qt-platform-plugin-xcb-in-even-though-it-was
But I don't see this as a KLayout issue. Conda packaging is not something I deal with here.
Matthias
I'll close this issue for now.
We are trying to use conda environment for the tools used by OpenRAM. I have a recipe for klayout (which I got from conda-eda and modified); however, some of our unit tests are failing. This is the setup I used to replicate one of these errors. You can install the conda environment (
install_conda.sh
) and run the DRC script (run_drc.sh
) to see the output below. We are using a specific commit of klayout (which works with Docker). You can see how we build klayout in the conda recipe. How can I solve this issue?