[Keith]

Sorry not seen this till now. You need to give more info – is there any logfile produced? Any windows popups appear? Have you run the VC redistributable to install the runtime libraries?

[Keith]

Try typing:

which glade

If you see something like /home/zois/Softwares/RTL_to_GDSII/Glade/glade4_linux64_ub20/bin/glade

then your PATH is set, and you can just type glade not ./glade

The latter will try and start an executable in the current directory, which is (usually) not what you want.

[Keith]

So u_strToLower is a function that is part of Unicode support. A grep on the QtCore source shows:

corelib/text/qlocale_icu.cpp:// caseFunc can either be u_strToUpper or u_strToLower
corelib/text/qlocale_icu.cpp: bool err = qt_u_strToCase(str, &out, localeID, u_strToLower);

u_strToLower is part of the unicode libraries. I’d also check libicu, libicui18n, libicuuc – although ldd says you have them.

[Keith]

The only other thing I can think is that one (or some) of the Qt plugins loaded by QtCore are missing dependencies. You could try checking the shared libs in the bin/platforms dir using ldd.

I suspect it’s a system library issue, unfortunately I have been unable to find any reference to a strToLower function to determine what.

[Keith]

That all looks normal. I can not see where the error message you are saying you get is coming from; the only possibility is that the libQt5Core library contains the QString functionality and that has the QString::toLower() function. But as long as you are using the supplied libQt5Core (which ldd says you are) then it should be ok. And it works fine on my 20.04 installation.

Have you tried reinstalling Glade?

[Keith]

Try running ‘ldd glade’ in the bin directory and posting the output. And then run ‘ldd libQt5Core.so.5.15.0’ in the lib directory.

Also what build of 20.04 are you running (type ‘uname -a’)?

[Keith]

libICU is required by Qt for Unicode support.

The CentOS8 build had failed alas, it has now been fixed.

[Keith]

But Glade does come with all the shared libs it needs, for the OS version it is compiled for, as a ‘ldd glade’ should show. Of course some other applications may need their own versions of the Qt libs, so setting LD_LIBRARY_PATH to point to the glade_linux64_**/lib dir will cause problems for them, but as Glade finds its required libraries using rpath, you don’t need to set that env var for Glade.

In terms of download popularity, CentOS is equal to Ubuntu in numbers. And both are 10x less than the number of Windows 64 bit downloads…

[Keith]

Strange, I've checked on the Linux platforms I build on, I don't see any issue.

Does this behaviour only occur using the FreePDK15 PCells? If you just load the techfile, then use File->New to create a cellView from a pcell python file, is the behaviour the same?

[Keith]

Please contact support@peardrop.co.uk for enquiries about advanced rules license support. Thanks.

[Keith]

Would need a testcase to debug this – not enough info from the stacktrace.

[Keith]

Yes the Finfet rules are licensed.

[Keith]

Strange it works fine for me. If you close any open layout and reopen, does that work?

I have seen an issue where if you close a window in certain circumstances, other windows appear 'frozen'. I wonder if that is the issue here.

[Keith]

In a schematic? Or a layout?

Either way I've added dummy virtual methods for line, arc and ellipse objects for the point in poly check. The current error message can be just ignored for now.

[Keith]

I've got a feeling I've fixed that recently. It's testing if a point is within a poly, this can happen for e.g. a label that does not have a real bounding box.

When is it occurring? With dynamic highlight on as you move the cursor over a shape?

[Author]

Posts