can't build under SUSE Enterprise Server 12 ..

29 views
Skip to first unread message

Gal Aviel

unread,
Sep 12, 2022, 8:14:01 AMSep 12
to Verible Users
Greetings!

I'm trying to build under SUSE Linux Enterprise Server 12 (x86_64).

I don't have root access.

I must say that the build process is very complicated and frustrating. 10 years ago it was as simple as configure; make; make install however nowadays you must spend 1/2 a day installing bazel...

Anyway I think I managed to compile bazel from source, I have a 'bazel-devel' binary.
When I try to run
"bazel-dev build -c opt --repository_cache /tmp/<user>/bazel_repo_cache/ //verilog/tools/syntax:verible-verilog-syntax"

I'm getting the below error message.
Any help is greatly appreciated!

thanks, Gal.
---
WARNING: Output base '/nfs/site/disks/home80/<user>/.cache/bazel/_bazel_<user>/5391d109076636e51abc1524bed7e4a3' is on NFS. This may lead to surprising failures and undetermined behavior.
Loading:
Loading: 0 packages loaded
Analyzing: target //verilog/tools/syntax:verible-verilog-syntax (0 packages loaded, 0 targets configured)
ERROR: /nfs/site/disks/home80/<user>/.cache/bazel/_bazel_<user>/5391d109076636e51abc1524bed7e4a3/external/bazel_tools/platforms/BUILD:89:6: in alias rule @bazel_tools//platforms:windows: Constraints from @bazel_tools//platforms have been removed. Please use constraints from @platforms repository embedded in Bazel, or preferably declare dependency on https://github.com/bazelbuild/platforms. See https://github.com/bazelbuild/bazel/issues/8622 for details.
ERROR: /nfs/site/disks/home80/<user>/.cache/bazel/_bazel_<user>/5391d109076636e51abc1524bed7e4a3/external/bazel_tools/platforms/BUILD:89:6: Analysis of target '@bazel_tools//platforms:windows' failed
ERROR: /tmp/<user>/verible/verilog/tools/syntax/BUILD:7:10: While resolving toolchains for target //verilog/tools/syntax:verible-verilog-syntax: invalid registered toolchain '@bazel_skylib//toolchains/unittest:cmd_toolchain':
ERROR: Analysis of target '//verilog/tools/syntax:verible-verilog-syntax' failed; build aborted:
INFO: Elapsed time: 0.094s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)


Henner Zeller

unread,
Sep 12, 2022, 2:07:43 PMSep 12
to Gal Aviel, Verible Users
On Mon, 12 Sept 2022 at 08:42, Henner Zeller <h.ze...@acm.org> wrote:
Hi Gal,
On Mon, 12 Sept 2022 at 05:14, Gal Aviel <galav...@gmail.com> wrote:
Greetings!

I'm trying to build under SUSE Linux Enterprise Server 12 (x86_64).

I don't have root access.

I must say that the build process is very complicated and frustrating. 10 years ago it was as simple as configure; make; make install however nowadays you must spend 1/2 a day installing bazel...

Yeah sorry, I feel you. Advantage of Bazel is, that it allows to describe dependencies hermetically, but disadvantage is, that it is a complicated, java-based system that is currently not very mainstream.


Anyway I think I managed to compile bazel from source, I have a 'bazel-devel' binary.

I have not recently used SUSE; but it seems like there are pre-installable binaries (I just found https://docs.bazel.build/versions/4.2.2/install-suse.html )
You need bazel version 4.

For the self-compilation, you probably need to do a lot of additional configuring, for instance what you local tooolchain is (gcc and such), at least that is what the error message w.r.t platform constraints and toolchain indicates below as a potential problem. Is it possible for you to test the pre-installable version of bazel ?

I could not reproduce the @platforms warning, what version of bazel did you compile ? i.e. what does the following command print ?

bazel-dev --version 


In the meantime, I will also check if the platform constraints can be formulated a bit differently (for context: these are essentially used for platform independent compilation rules, something like 'on windows, don't add this warning flag').

We should maybe also consider adding OpenSUSE-compatible pre-compiled binaries in the releases (https://github.com/chipsalliance/verible/releases)


Cheers,
  Henner.


Hope this helps to get this sorted out.
  Henner.

When I try to run
"bazel-dev build -c opt --repository_cache /tmp/<user>/bazel_repo_cache/ //verilog/tools/syntax:verible-verilog-syntax"

I'm getting the below error message.
Any help is greatly appreciated!

thanks, Gal.
---
WARNING: Output base '/nfs/site/disks/home80/<user>/.cache/bazel/_bazel_<user>/5391d109076636e51abc1524bed7e4a3' is on NFS. This may lead to surprising failures and undetermined behavior.
Loading:
Loading: 0 packages loaded
Analyzing: target //verilog/tools/syntax:verible-verilog-syntax (0 packages loaded, 0 targets configured)
ERROR: /nfs/site/disks/home80/<user>/.cache/bazel/_bazel_<user>/5391d109076636e51abc1524bed7e4a3/external/bazel_tools/platforms/BUILD:89:6: in alias rule @bazel_tools//platforms:windows: Constraints from @bazel_tools//platforms have been removed. Please use constraints from @platforms repository embedded in Bazel, or preferably declare dependency on https://github.com/bazelbuild/platforms. See https://github.com/bazelbuild/bazel/issues/8622 for details.
ERROR: /nfs/site/disks/home80/<user>/.cache/bazel/_bazel_<user>/5391d109076636e51abc1524bed7e4a3/external/bazel_tools/platforms/BUILD:89:6: Analysis of target '@bazel_tools//platforms:windows' failed
ERROR: /tmp/<user>/verible/verilog/tools/syntax/BUILD:7:10: While resolving toolchains for target //verilog/tools/syntax:verible-verilog-syntax: invalid registered toolchain '@bazel_skylib//toolchains/unittest:cmd_toolchain':
ERROR: Analysis of target '//verilog/tools/syntax:verible-verilog-syntax' failed; build aborted:
INFO: Elapsed time: 0.094s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)


--
You received this message because you are subscribed to the Google Groups "Verible Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to verible-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/verible-users/674e8755-7f61-43dc-8a39-cd0bc22b0f06n%40googlegroups.com.

Gal Aviel

unread,
Sep 13, 2022, 3:14:27 AMSep 13
to Verible Users
Hi  Henner,

Really appreciate your reply! Thanks allot!
I've build a flow around verible and have invested a few days' work into that, so it's important for me not to loose this investment.

Trying to answer specifically:

1. OpenSuse binaries: can't use zypper - since I don't have root access. I work in a big corporation and don't have root. Tried work-arounds such as https://unix.stackexchange.com/questions/171568/zypper-how-to-install-a-package-in-local-bin-directory however still doesn't work - zypper won't let me even download the binaries without root access. Even if I could - would openSuse binaries work on Suse enterprise 12? 

2.  bazel-dev --version : since building 'verible' failed, I thought the issue might be with 'bazel' so I've cloned latest (git clone https://github.com/bazelbuild/bazel) and build it (bazel build //src:bazel-dev --repository_cache /tmp/<user>/bazel_repo_cache). Thinking perhaps the stable release of bazel isn't up to date for verible.
Again, not trivial and I'm not sure I got it right - you need to boot-strap by downloading the stable release 5.3). 

Also note I'm running on /tmp since bazel keeps complaining that running on NFS is bad...
Anyway, bazel-dev --version returns:
[FATAL 10:02:47.134 src/main/cpp/archive_utils.cc:67] Failed to find member 'build-label.txt' in zip file '/tmp/<user>/.cache/bazel/_bazel_<user>/08e1fc2229922b3ac823cfaf4c7d918f/execroot/io_bazel/bazel-out/k8-fastbuild/bin/src/bazel-dev'
So again I'm not sure what's going on.

So I'm in a dead end here. Further things I'd like to mention:

3. Consider that many of verible's potential users might work in big corporations, where distro's such as Enterprise Suse and/or RHEL are very common, whereas they might be less common in the open source world. So you would potentially miss out of those users.

4.Is there a possibility to provide a *statically-linked* binary for linux X64? Even if such a binary would be much bigger, for me this is a doable option.

5. Just an observation, again working with bazel is non trivial. It seems 'bazel' doesn't like NFS (NFS or other networked file systems are a must for corporate users...) and it also keeps using my home directory's .cache - again corroborate users have very limited space there.. so it's quite problematic.

Perhaps static binaries are the way to go ? 

Any help appreciated, thanks, Gal.

Gal Aviel

unread,
Sep 13, 2022, 3:18:43 AMSep 13
to Verible Users
Just to complete the picture, tools I'm using to compile bazel-dev and verible (it's been a while since I've compiled stuff on Linux, hope I got this right):

setenv HOME /tmp/<user> (to avoid my original home dir from filling up ... which might fail the build...)
setenv CC /usr/<company>/pkgs/gcc/10.3.0/bin/gcc
setenv PATH /usr/<company>/pkgs/gcc/10.3.0/bin/:$PATH
setenv JAVA_HOME /usr/<company>/pkgs/openjdk/11.0.10/

I've got lots of common packages in the above path, so I can choose e.g. a different GCC version if needed.
thanks, Gal.

Henner Zeller

unread,
Sep 13, 2022, 11:43:25 AMSep 13
to Gal Aviel, Verible Users
Hi Gal,
 
1. OpenSuse binaries: can't use zypper - since I don't have root access. I work in a big corporation and don't have root. Tried work-arounds such as https://unix.stackexchange.com/questions/171568/zypper-how-to-install-a-package-in-local-bin-directory however still doesn't work - zypper won't let me even download the binaries without root access. Even if I could - would openSuse binaries work on Suse enterprise 12? 

Not entirely sure, but since bazel is mostly java, it probably depends more on the JDK. Anyway, looks like this route won't work.
 
2.  bazel-dev --version : since building 'verible' failed, I thought the issue might be with 'bazel' so I've cloned latest (git clone https://github.com/bazelbuild/bazel) and build it (bazel build //src:bazel-dev --repository_cache /tmp/<user>/bazel_repo_cache). Thinking perhaps the stable release of bazel isn't up to date for verible.
Again, not trivial and I'm not sure I got it right - you need to boot-strap by downloading the stable release 5.3). 

For verible, you actually only need bazel 4.x. 5.3 should work as well. I actually haven't tested it with git latest, but it might as well be that it won't quite work with that yet.
So if you can, an older version 4.0..5.3 version is probably better.

Also note I'm running on /tmp since bazel keeps complaining that running on NFS is bad...
Anyway, bazel-dev --version returns:
[FATAL 10:02:47.134 src/main/cpp/archive_utils.cc:67] Failed to find member 'build-label.txt' in zip file '/tmp/<user>/.cache/bazel/_bazel_<user>/08e1fc2229922b3ac823cfaf4c7d918f/execroot/io_bazel/bazel-out/k8-fastbuild/bin/src/bazel-dev'
So again I'm not sure what's going on.

Ok, sounds like the built version of bazel is hosed. You mentioned that you had to downloaded a stable 5.3 release to bootstrap. Was that also not able to compile verible ?

This would be some typical output
$ bazel --version
bazel 5.1.1

3. Consider that many of verible's potential users might work in big corporations, where distro's such as Enterprise Suse and/or RHEL are very common, whereas they might be less common in the open source world. So you would potentially miss out of those users.

Noted. We do build for CentOS as this seems to be also a common os outside the open source world, but I've now added to the ΤODO list to include SUSE.
 
4.Is there a possibility to provide a *statically-linked* binary for linux X64? Even if such a binary would be much bigger, for me this is a doable option.

The binaries in https://github.com/chipsalliance/verible/releases are actually already 'mostly static', i.e. they mostly only really rely on libc and libm to be dynamic to run.
So I am wondering if you download a version for some other distribution that is sufficiently similar to the Enterprise SUSE, maybe it already works ?

The tar files contain binaries in the versioned directory, e.g. in the current release tars in https://github.com/chipsalliance/verible/releases/tag/v0.0-2297-gd7d32592 the verible-verilog-syntax can be found in
     verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax

So you could quickly see if they work by invoking it with --version
     verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax --version

If not, let's see where the dynamic linker has an issue. What does
     ldd verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax
print ?


5. Just an observation, again working with bazel is non trivial. It seems 'bazel' doesn't like NFS (NFS or other networked file systems are a must for corporate users...) and it also keeps using my home directory's .cache - again corroborate users have very limited space there.. so it's quite problematic.

You can override the path where bazel stores its local cache with the --output_user_root flag
     bazel --output_user_root=/tmp/bazel-cache build //...
That way, everything goes to the specified directory.
 
You can also configure that in a ~/.bazelrc configuration file in your home directory 
$ cat ~/.bazelrc  
startup --output_user_root=/tmp/bazel-cache

Cheers,
  Henner.

Gal Aviel

unread,
Sep 13, 2022, 12:01:54 PMSep 13
to Verible Users
Hi Henner,

Thanks for the plethora of useful paths to follow / information / tips - highly appreciated. 
I'm learning here. Coming back after many years to a DA (Design Automation) related job, it seems the tools and eco-system has indeed changed a bit, your suggestions and tips are highly appreciated!  

I will try the pre-build binaries now.
Thanks again, Gal.

Gal Aviel

unread,
Sep 13, 2022, 12:22:44 PMSep 13
to Verible Users
downloaded verible-v0.0-2297-gd7d32592-CentOS-7.9.2009-Core-x86_64.tar.gz and tried to run it.

Getting:

>ldd ../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax
../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax)
../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by ../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax)
        linux-vdso.so.1 =>  (0x00007ffff7ffe000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffff7d62000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ffff7b58000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffff793b000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff7724000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffff73a7000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

let met try another distro (ubuntu 16.. I think Suse Enterprise 12 is ancient so I'm better off with an older Ubuntu)

will update, thanks, Gal.

Gal Aviel

unread,
Sep 13, 2022, 12:30:06 PMSep 13
to Verible Users
by mistake the last run was on Suse 11.4 and not 12 as I thought (Ran on our VNC hosting machine not the strong workstations..)

Anyway the Ubuntu-16 binary seems run happily under Suse Enterprise 12:

>ldd ../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax
        linux-vdso.so.1 (0x00007ffff7ffa000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
        libpthread.so.0 => /lib64/noelision/libpthread.so.0 (0x00007ffff78c1000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff76a9000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffff7304000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)

Indeed very few dependancies ...

Thanks allot !!! I'm a happy campter :)

Ok now that I have it running - I can now batch run it on all our standard modules ! 
Huge thanks !!

Gal.

Henner Zeller

unread,
Sep 13, 2022, 12:57:51 PMSep 13
to Gal Aviel, Verible Users
On Tue, 13 Sept 2022 at 09:30, Gal Aviel <galav...@gmail.com> wrote:
by mistake the last run was on Suse 11.4 and not 12 as I thought (Ran on our VNC hosting machine not the strong workstations..)

Anyway the Ubuntu-16 binary seems run happily under Suse Enterprise 12:

>ldd ../../../downloads/verible-v0.0-2297-gd7d32592/bin/verible-verilog-syntax
        linux-vdso.so.1 (0x00007ffff7ffa000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
        libpthread.so.0 => /lib64/noelision/libpthread.so.0 (0x00007ffff78c1000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff76a9000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffff7304000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)

Indeed very few dependancies ...

Thanks allot !!! I'm a happy campter :)

Ok now that I have it running - I can now batch run it on all our standard modules ! 

Cool, let the list know how it goes. There are known limitations for some SystemVerilog constructs and in particular when preprocessor
macros are involved, but this is being worked on. Also I think some syntax elements in SystemVerilog Assertions are not supported yet.
So if you find particular constructs that don't work that would be useful. SystemVerilog is big and everyone uses their relevant
subset, so knowing what subsets to make sure to work well is important to us.

We appreciate such feedback so that we know what are the most important things to prioritize next.

Thanks,
  Henner.

Gal Aviel

unread,
Sep 15, 2022, 4:04:02 AMSep 15
to Verible Users
Sure thing, will do.

Currently I'm interested in SystemVerilog for Design only, and actually a very limited sub-set of that.
(because the modules being parsed are now owned by me or at least so I can basically dictates coding styles to make them simple and easy to parse).

Currently the application is (hope I'm not repeating myself..) generating a PDF data-book like document for our common re-usable Verilog modules (FIFOs, synchronizers, etc. common stuff). I borrowed and example from lowRisk where they also seemed to have switched to verible for that purpose (in favor of some home brewed regular expression stuff..).
So I'm doing pretty much the same. (verible-verilog-syntax --export_json --printtree ...)

Using some other open source tools such as rst2pdf and dot/graphwiz to generate the PDF and the PNG symbol for each module (inputs, outputs, etc.)

Is there any direct Python interface planned for verible? instead of exporting JSON and parsing it in Python...?
is this an area where you would like some help ? 

Thanks, Gal.
Reply all
Reply to author
Forward
0 new messages