search

KLayout / klayout

KLayout Main Sources
http://www.klayout.org
GNU General Public License v3.0
788 stars 202 forks source link

MacOS: no file formats in open/save (can't open/save GDS, OASIS etc.) #566

Closed demisjohn closed 4 years ago

demisjohn commented 4 years ago

Can't open/save into GDS format (or any other format), on the MacOS 10.13 or 10.14 package of v0.26.5: https://www.klayout.org/downloads/MacOS/ST-klayout-0.26.5-macOS-HighSierra-1-qt5MP-RsysPsys.dmg

"All layout files" dropdown in open/save dialogues shows an empty list of formats: Screen Shot 2020-05-24 at 8 48 42 AM

Attached Screenshot of empty "format" dropdown list in the Save dialog for a brand new layout: Screen Shot 2020-05-24 at 8 37 15 AM

v0.26.4, the previous version, also appears to have this issue. Renaming ~/.klayout or the klayout.de preference file doesn't fix.

This problem doesn't exist in v0.25.9, on either MacOS 10.13 or 10.14 packages, on two separate machines (2010 MacBookPro and 2017 MacBookPro, respectively).

lukasc-ubc commented 4 years ago

It works for me on:

klayout 0.26.5 HW-klayout-0.26.5-macOS-Catalina-1-qt5Brew-RsysPhb37 and klayout 0.26.5-macOS-Catalina-1-qt5MP-RsysPsys

I wonder if this might be due to permissions. I notice that KLayout is often asking for permission to access various folders. It seems like Mac OSX has increased security preventing applications from reading files. Maybe it can’t read a file that lists the formats?

klayoutmatthias commented 4 years ago

That's definitely not an issue of the release.

Please check your installation: the plugins for the stream formats are kept in a folder called "db_plugins" next to a file called (I think) "libklayout_db.dylib" in the installation folder. In this folder you should find the stream format drivers like "libgds2.dylib" etc.

When you run KLayout with high debug level (klayout -d 41) you should see the paths being scanned. On my Linux box this is:

Scanning for db plugins: /home/matthias/.klayout/db_plugins
Scanning for db plugins: /usr/bin/db_plugins
Scanning for db plugins: /usr/bin/x86_64-linux-gcc/db_plugins
Scanning for db plugins: /usr/lib/klayout/db_plugins
Loading plugin: /usr/lib/klayout/db_plugins/libcif.so
Registered object 'CIF' with priority 2100
Loading plugin: /usr/lib/klayout/db_plugins/libdxf.so
Registered object 'DXF' with priority 2000
Loading plugin: /usr/lib/klayout/db_plugins/libgds2.so
Registered object 'GDS2Text' with priority 1
Registered object 'GDS2' with priority 0
Loading plugin: /usr/lib/klayout/db_plugins/liblefdef.so
Registered object 'LEFDEF' with priority 500
Loading plugin: /usr/lib/klayout/db_plugins/libmag.so
Registered object 'MAG' with priority 2200
Loading plugin: /usr/lib/klayout/db_plugins/libnet_tracer.so
Registered object 'NetTracerPlugin' with priority 13000
Loading plugin: /usr/lib/klayout/db_plugins/liboasis.so
Registered object 'OASIS' with priority 10
Loading plugin: /usr/lib/klayout/db_plugins/libpcb.so
Registered object 'GerberPCB' with priority 1000
...

Note that on Linux, the suffix for shared objects is ".so" while it is ".dylib" on MacOS.

Matthias

demisjohn commented 4 years ago

On my 2017 MacBookPro w/ MacOS 10.14.2, after running in -d mode (and accidentally launching the old 0.25.9 version a few times), the issue magically resolved itself - v0.26.5 can open all layout formats and the dropdown menus show the typical formats, even under normal double-click launch. I had to re-copy the executable from the 0.26.5 DMG and re-enable the software launch option "Open even though downloaded from the internet from unverified publisher".

Issue solved through some unknown reason on the Mac OS 10.14 / 2017 MacBook Pro for v0.26.5.

On my 2010 MacBook Pro w/ 10.13.6, however, the issue is stranger: When I run Layout in debug mode 41 from the CLI, all the formats are available. I was able to open a DXF drawing as normal, multiple times.

However if I run not in debug mode, just by double-clicking the executable file, I get the empty format dropdown, and attempting to open the same DXF, I get this error, same as reported in the OP when opening a file: Screen Shot 2020-05-24 at 7 55 37 PM (Open/Save menus also show empty Formats lists)

Any other info I can provide to debug? I suppose I can download the 10.14 Klayout version and try running that on 10.13 and see if the issue occurs (each laptop has the different KLayout distribution on it, matching the different OS versions).

Maybe a MacOS 'sandboxing' issue due to the 'unverified publisher' security check? I will try disabling this, and also re-copying from DMG on the 10.13 laptop.

Kazzz-S commented 4 years ago

Hi @demisjohn,

I have built the High Sierra package on my VMware virtual machine (the host is MacBook Pro Mid. 2012 w/ Yosemite 10.10.5), and the issue does not reproduce, as shown below. It's weird.

OS and Package

566-No1 566-No2

Open

566-No3

Save as

566-No4 566-No5

-d 41

klayout-0.26.5-HighSierra-d41.log.zip

Scanning for db plugins: /Users/sekigawa/.klayout/db_plugins
Scanning for db plugins: /Users/sekigawa/.klayout/x86_64-linux-clang/db_plugins
Scanning for db plugins: /Applications/klayout.app/Contents/MacOS/db_plugins
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/libcif.0.dylib
Registered object 'CIF' with priority 2100
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/libdxf.0.dylib
Registered object 'DXF' with priority 2000
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/libgds2.0.dylib
Registered object 'GDS2Text' with priority 1
Registered object 'GDS2' with priority 0
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/liblefdef.0.dylib
Registered object 'LEFDEF' with priority 500
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/libmag.0.dylib
Registered object 'MAG' with priority 2200
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/libnet_tracer.0.dylib
Registered object 'NetTracerPlugin' with priority 13000
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/liboasis.0.dylib
Registered object 'OASIS' with priority 10
Loading plugin: /Applications/klayout.app/Contents/MacOS/db_plugins/libpcb.0.dylib
Registered object 'GerberPCB' with priority 1000
:
:

No idea about additional info to debug. Sorry about that. Regards, Kazzz-S

P.S. This may not help, but what would happen if you remove a white space character (maybe) between DeepSpace and Lubin in the directory name?

demisjohn commented 4 years ago

On the 2010, 10.13 MacBook Pro: db_plugins folder is present, with appropriate items:

Screen Shot 2020-05-26 at 1 55 41 PM

Launching via CLI with the -d 41 option, debug output shows that it is loading the plugins, AND the Open dialogue shows the expected file formats: Screen Shot 2020-05-26 at 2 00 21 PM

Debug CLI output attached. klayout -d 41 v0.26.5 (10.13).rtf.zip

If I launch Klayout from the command-line with NO debug, just ./klayout (from within the klayout.app/ folder) I can now see all the file formats in the dropdown, and it acts as normal! Able to load a GDS layout like normal.

Again, double-clicking the Layout icon results in NO file formats available (how can I get debugging output in this state?) Screen Shot 2020-05-26 at 2 02 19 PM

Which begs the question: On Mac OS 10.13, what is different about double-clicking the icon versus launching via CLI? And on Mac OS 10.14, what happened such that the OS magically fixed the difference?

klayoutmatthias commented 4 years ago

Hi,

I think the CLI version works because of the current directory.

I'm not a Mac user myself but I recall KLayout is usually called through some script on MacOS. Maybe running that directly isn't supported at all?

Technically the reason might be the dynamic linker load path (LD_LIBRARY_PATH on Linux, DYLD_LIBRARY_PATH on MacOS). Maybe setting this environment variable to the installation path of KLayout will give you the stream formats.

On Linux the installation path is predefined and built into the binary (RPATH). Hence this isn't a problem. On Windows, DLL search includes relative to the binary, so that's not a problem either. On Mac I can't tell.

Matthias

demisjohn commented 4 years ago

Could it be picking up a different python installation (both latops have macports python27 & python35 installed from macports), which messed up the cwd?

That is perhaps one thing I have on both laptops that could be uncommon to many users.

Kazzz-S commented 4 years ago

Could it be picking up a different python installation (both latops have macports python27 & python35 installed from macports), which messed up the cwd?

That is perhaps one thing I have on both laptops that could be uncommon to many users.

I think you have installed ST-klayout-0.26.5-macOS-HighSierra-1-qt5MP-RsysPsys.dmg. This package should attempt to link the OS-bundled Ruby and Python; not from MacPorts. But Qt5 Frameworks from MacPorts are embedded. Have you globally set PYTHONHOME environment variable to the Python from MacPorts under /opt/local/?

I'll post the next comment shortly.

Kazzz-S

Kazzz-S commented 4 years ago

Hi,

If possible, please try the following steps. 1. OS Update (released today!) 566-No11

2. Completely uninstall klayout.app (including old versions if any) 566-No12

3. Also move $HOME/.klayout directory

4. Reinstall klayout.app from the DMG installer 566-No13

5. Open klayout.app from Finder

6. Using script bundles: this is optional

Kazzz-S

Kazzz-S commented 4 years ago

Hi @demisjohn,

Knowing that you are a MacPorts user, I have built a special package for HighSierra. Please give a shot at it if you like.

Visit Dropbox and download LW-klayout-0.26.5-macOS-HighSierra-4-qt5MP-Rmp26Pmp37.dmg.

This package is special because it:

HighSierra:MacOS sekigawa$ otool -L klayout | grep ruby /opt/local/lib/libruby.2.6.dylib (compatibility version 2.6.0, current version 2.6.6)

HighSierra:MacOS sekigawa$ otool -L klayout | grep Python /opt/local/Library/Frameworks/Python.framework/Versions/3.7/Python (compatibility version 3.7.0, current version 3.7.0)


As you can see above, you need to install (1) qt5, (2) ruby26, (3) python37 by ``sudo port install``.

![566-No21](https://user-images.githubusercontent.com/16847255/83073998-5ccd5100-a0ac-11ea-9ebc-65f5e20532e9.png)
![566-No22](https://user-images.githubusercontent.com/16847255/83074008-6060d800-a0ac-11ea-8330-078f33125238.png)

Kazzz-S
demisjohn commented 4 years ago

(on the 2010 MacOS 10.13.6):

OK I figured it out!

I usually keep Klayout in a subfolder /Applications/KLayout ƒ (I keep old KLayout versions in case of issues like this). Changing the directory to /Applications/KLayout f (regular 'F') fixed the issue. So having an unusual character in the path to the executable breaks the file formats for some reason.

While Launching from CLI (even with the strange directory name) does not encounter this problem! (For example, I can paste the following into the CLI and get a fully functional Klayout: /Applications/KLayout\ ƒ/klayout.app/Contents/MacOS/klayout )

(I've been using that folder name for years without issue, go figure...)

FYI, I tried the suggested fixes - using AppCleaner to remove KLayout, removing ~/.klayout, re-downloading and right-click>Open (while holding ⇧ to enable the "open from unidentified developer") - same behavior. Still no file-formats in the open/save dialog, but from CLI running /Applications/KLayout\ ƒ/klayout.app/Contents/MacOS/klayout does show all the expected file formats.

If I do env I see no variable named PYTHONHOME or anything related (nothing at all to do with Python it seems).

My available python commands (tab-complete options):

<<demis@TheLionofJudah:MacOS [20:10:31]> python  <<Tab,Tab>>
python             python3            python3.6m-config  pythontex
python-config      python3-config     python3.8          pythonw
python.app         python3.6          python3.8-config   pythonw2.7
python2.7          python3.6-config   python3m           
python2.7-config   python3.6m         python3m-config    
<<demis@TheLionofJudah:MacOS [20:10:31]> which python
/opt/local/bin/python
demisjohn commented 4 years ago

I closed this, but perhaps you don't necessarily want KLayout to be sensitive to OS-permitted but non-ASCII characters. However, I assume this is merely an edge-case, so ok to leave unfixed.

Hopefully it doesn't point to other possible breakages in the future, as something certainly changed from 0.25.x to 0.26.x to cause this to break. I leave that to you both to decide.

Thanks for helping me try things, sorry for not noticing that before.