quartus_map crash, possibly due to shared library shenanigans

Hi Richard,

alas, there is no environment variable to override what applications are doing through libdl, the environment affects only normal library loading.

This is Quartus Lite 20.1.1.720 on Debian Linux, once installed normally on a laptop, and once installed into Docker as follows:

1. First, import the installer tar as a Docker image:

   docker import Quartus-lite-20.1.1.720-linux.tar quartus-installer:20.1.1.720​

2. Then, build this Dockerfile:

   FROM debian
   RUN [ "apt-get", "update" ]
   RUN [ "apt-get", "--yes", "install", "gcc" ]
   ADD hack.c hack.c
   RUN [ "gcc", "-shared", "-o", "hack.so", "hack.c", "-ldl" ]
   
   FROM debian
   COPY --from=quartus-installer:20.1.1.720 / /tmp/setup
   RUN [ "/tmp/setup/setup.sh", \
           "--accept_eula", "1", \
           "--mode", "unattended", \
           "--unattendedmodeui", "none", \
           "--installdir", "/opt/altera/20.1" ]
   
   FROM debian
   COPY --from=1 /opt/altera /opt/altera
   RUN [ "apt-get", "update" ]
   RUN [ "apt-get", "--yes", "install", "--no-install-recommends", \
    "locales", \
    "libfontconfig1", \
    "libglib2.0-0", \
    "libxrender1", \
    "libxtst6", \
    "make", \
    "xauth", \
    "xvfb" ]
   RUN [ "sed", "-i", "-e", "/en_US\\.UTF-8/s/^# *//", "/etc/locale.gen" ]
   RUN [ "locale-gen" ]
   COPY --from=0 hack.so /opt/hack.so
   ADD ld.so.preload /etc/ld.so.preload
   RUN [ "useradd", "build" ]
   USER build​

Remarks:

1. The "ld.so.preload" file just points to /opt/hack.so, so it is added to every process, this allows the compiler to work.
2. The "hack.c" file is from the other post.
3. I install "locales" and generate the "en_US" locale to avoid some warnings.
4. The four libraries are required as system libraries because they aren't shipped with QuartusII.
5. I have to add GNU Make or the sequencer of the UniPHY based memory controller fails to build. That is a bit weird because GNU Make is included in the Quartus distribution package.
6. I pack a virtual X server and xauth in there so I can regenerate IP components. For some reason, mw-regenerate falls over without a display present, even if it's just generating, so Jenkins is instructed to set up a fake display.

This is where I'm at currently, this seems to be generally working for everything but Qsys, so most of my projects are covered by that, but the amount of trickery I needed to make this reproducible is still a bit high. After all, the goal is to be able to generate programming files on a central server and become independent from developers' workstations.

This post already describes the Qsys problem: I cannot reference the Verilog modules generated from Qsys from a VHDL toplevel file.

The Qsys generator looks at ~/.altera.quartus/quartus2.ini to see whether it should generate VHDL or Verilog, so a project that compiles fine on my laptop (where the preference is set to VHDL) will fail when I run it over night on the server where the INI file doesn't exist and it falls back to Verilog.

This problem can be reproduced with a simple test project, which I've attached: whether this compiles depends on the setting of Tools->Options->IP Settings->IP Generation HDL Preference: in VHDL mode it succeeds and in Verilog mode, it fails.

Simon