Failed to load library libOpenCL.so.1, although it existsSafenet Authentication Client Tools error when...

What does a comma signify in inorganic chemistry?

Why should P.I be willing to write strong LOR even if that means losing a undergraduate from his/her lab?

Why should I pay for an SSL certificate?

A reccomended structured approach to self studying music theory for songwriting

Spongy green glass found on graves

What allows us to use imaginary numbers?

Do I need to start off my book by describing the character's "normal world"?

What is the opposite of "hunger level"?

Pocket Clarketech

Why do so many people play out of turn on the last lead?

May the tower use the runway while an emergency aircraft is inbound?

From where do electrons gain kinetic energy through a circuit?

How do I cope with haze for the photos containing sky and trees at a distance?

Postdoc interview - somewhat positive reply but no news?

Representing an indicator function: binary variables and "indicator constraints"

Can planar set contain even many vertices of every unit equilateral triangle?

Eric Andre had a dream

Vegetarian dishes on Russian trains (European part)

Tikz: The position of a label change step-wise and not in a continuous way

C++ Least cost swapping 2

Why is the battery jumpered to a resistor in this schematic?

Output with the same length always

Quick destruction of a helium filled airship?

Gofer work in exchange for Letter of Recommendation



Failed to load library libOpenCL.so.1, although it exists


Safenet Authentication Client Tools error when Reboot or restart the eTSrv- and pcscd-servicesWhy does chroot get ENOENT on an existing file?headless firefox failed on aws amazon linuxcan't sudo mv libtinfo.so.5.bak libtinfo.so.5Error while loading shared libraries: internal errorPHP Startup: Unable to load dynamic library : cannot open shared object file: No such file or directory






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







0















I have installed ocl-icd-opencl-dev and I try to run a simple OpenCL app, called vadd:



$ ./vadd
./vadd: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory


I have followed this, and the output looks as follows (I 've kept only the interesting part):



$ strace -f -v -s150 ./vadd 2>&1 | fgrep libOpenCL.so.1
...
open("/usr/lib/x86_64-linux-gnu/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...


Well...



$ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


What am I missing here? Is it a problem that libOpenCL.so.1 is a symlink?










share|improve this question







New contributor



Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




























    0















    I have installed ocl-icd-opencl-dev and I try to run a simple OpenCL app, called vadd:



    $ ./vadd
    ./vadd: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory


    I have followed this, and the output looks as follows (I 've kept only the interesting part):



    $ strace -f -v -s150 ./vadd 2>&1 | fgrep libOpenCL.so.1
    ...
    open("/usr/lib/x86_64-linux-gnu/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    ...


    Well...



    $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
    lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


    What am I missing here? Is it a problem that libOpenCL.so.1 is a symlink?










    share|improve this question







    New contributor



    Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.
























      0












      0








      0








      I have installed ocl-icd-opencl-dev and I try to run a simple OpenCL app, called vadd:



      $ ./vadd
      ./vadd: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory


      I have followed this, and the output looks as follows (I 've kept only the interesting part):



      $ strace -f -v -s150 ./vadd 2>&1 | fgrep libOpenCL.so.1
      ...
      open("/usr/lib/x86_64-linux-gnu/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      ...


      Well...



      $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
      lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


      What am I missing here? Is it a problem that libOpenCL.so.1 is a symlink?










      share|improve this question







      New contributor



      Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      I have installed ocl-icd-opencl-dev and I try to run a simple OpenCL app, called vadd:



      $ ./vadd
      ./vadd: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory


      I have followed this, and the output looks as follows (I 've kept only the interesting part):



      $ strace -f -v -s150 ./vadd 2>&1 | fgrep libOpenCL.so.1
      ...
      open("/usr/lib/x86_64-linux-gnu/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      ...


      Well...



      $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
      lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


      What am I missing here? Is it a problem that libOpenCL.so.1 is a symlink?







      linux shared-library






      share|improve this question







      New contributor



      Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.










      share|improve this question







      New contributor



      Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      share|improve this question




      share|improve this question






      New contributor



      Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      asked 2 days ago









      ZehanortZehanort

      11 bronze badge




      11 bronze badge




      New contributor



      Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




      New contributor




      Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.



























          2 Answers
          2






          active

          oldest

          votes


















          1














          It's not the issue that libOpenCL.so.1 is a symlink, but that it is a broken symlink.



          $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
          lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


          The above output shows only the symlink which points to the "real" file libOpenCL.so.1.0.0. However, that file should exist in the same directory, but it is not available. That is why the strace output reports ENOENT when trying to read the file.






          share|improve this answer


























          • Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

            – Zehanort
            2 days ago











          • You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

            – QIS
            2 days ago





















          0














          I managed to solve this, so I am posting what I did in case anybody falls in the same pit.



          First of all, I did have a broken symlink here:



          $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
          lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


          I had OpenCL installed via the Intel SDK for OpenCL Applications, and I had messed things up with the installation a little.



          What I found after some digging is that the Intel SDK installation installs the OpenCL shared libraries -having in mind changes in year and versions- in /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/.
          For my system (Linux Mint), this is the default location (the only thing you can change during the installation is /opt/intel/). In fact, it looks something like this:



          $ ls -l /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/ | grep libOpenCL
          lrwxrwxrwx 1 root root 16 Aug 16 04:35 libOpenCL.so -> ./libOpenCL.so.1
          lrwxrwxrwx 1 root root 18 Aug 16 04:35 libOpenCL.so.1 -> ./libOpenCL.so.2.0
          -rwxr-xr-x 1 root root 48216 Sep 21 2018 libOpenCL.so.2.0


          This means that the only "actual" file is libOpenCL.so.2.0 and there is a train of symlinks: libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0.



          Furthermore, I found out that there is a number of symlinks in /etc/alternatives/, that look quite OK (basically, what I understood is that they resolve the number at the end of the library name and serve as a middleman in case something changes at the actual libraries - which are all the same in my system, as I pointed out before):



          $ ls -l /etc/alternatives/ | grep OpenCL
          lrwxrwxrwx 1 root root 115 Aug 16 04:35 opencl-libOpenCL.so -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so
          lrwxrwxrwx 1 root root 117 Aug 16 04:35 opencl-libOpenCL.so.1 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1
          lrwxrwxrwx 1 root root 119 Aug 16 04:35 opencl-libOpenCL.so.2.0 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0


          So, the simplest thing I could do was to completely remove the broken symlink above (just rm) and create 3 new symlinks, one for each number at the end of the library name, just to be sure:



          $ cd /usr/lib/x86_64-linux-gnu
          $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so libOpenCL.so
          $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.1 libOpenCL.so.1
          $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.2.0 libOpenCL.so.2.0


          Now, the /usr/lib/x86_64-linux-gnu directory looks like this and everything seems to work:



          $ ls -l /usr/lib/x86_64-linux-gnu/ | grep OpenCL
          lrwxrwxrwx 1 root root 37 Aug 16 04:47 libOpenCL.so -> /etc/alternatives/opencl-libOpenCL.so
          lrwxrwxrwx 1 root root 39 Aug 16 04:47 libOpenCL.so.1 -> /etc/alternatives/opencl-libOpenCL.so.1
          lrwxrwxrwx 1 root root 41 Aug 16 04:35 libOpenCL.so.2.0 -> /etc/alternatives/opencl-libOpenCL.so.2.0





          share|improve this answer








          New contributor



          Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.
























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });






            Zehanort is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f535805%2ffailed-to-load-library-libopencl-so-1-although-it-exists%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            1














            It's not the issue that libOpenCL.so.1 is a symlink, but that it is a broken symlink.



            $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
            lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


            The above output shows only the symlink which points to the "real" file libOpenCL.so.1.0.0. However, that file should exist in the same directory, but it is not available. That is why the strace output reports ENOENT when trying to read the file.






            share|improve this answer


























            • Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

              – Zehanort
              2 days ago











            • You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

              – QIS
              2 days ago


















            1














            It's not the issue that libOpenCL.so.1 is a symlink, but that it is a broken symlink.



            $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
            lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


            The above output shows only the symlink which points to the "real" file libOpenCL.so.1.0.0. However, that file should exist in the same directory, but it is not available. That is why the strace output reports ENOENT when trying to read the file.






            share|improve this answer


























            • Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

              – Zehanort
              2 days ago











            • You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

              – QIS
              2 days ago
















            1












            1








            1







            It's not the issue that libOpenCL.so.1 is a symlink, but that it is a broken symlink.



            $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
            lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


            The above output shows only the symlink which points to the "real" file libOpenCL.so.1.0.0. However, that file should exist in the same directory, but it is not available. That is why the strace output reports ENOENT when trying to read the file.






            share|improve this answer













            It's not the issue that libOpenCL.so.1 is a symlink, but that it is a broken symlink.



            $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
            lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


            The above output shows only the symlink which points to the "real" file libOpenCL.so.1.0.0. However, that file should exist in the same directory, but it is not available. That is why the strace output reports ENOENT when trying to read the file.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 2 days ago









            QISQIS

            1017 bronze badges




            1017 bronze badges
















            • Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

              – Zehanort
              2 days ago











            • You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

              – QIS
              2 days ago





















            • Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

              – Zehanort
              2 days ago











            • You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

              – QIS
              2 days ago



















            Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

            – Zehanort
            2 days ago





            Hmm... Do you have any idea how to fix this? Purging and reinstalling ocl-icd-opencl-dev doesn't seem to work...

            – Zehanort
            2 days ago













            You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

            – QIS
            2 days ago







            You don't state what distribution you are running. Assuming Ubuntu, make sure you run apt-get purge ocl-icd-opencl-dev; apt-get autoremove; apt-get install ocl-icd-opencl-dev. That said, if you are running Ubuntu, you shouldn't have seen this problem in the first place. You might want to look at the package contents for ocl-icd-opencl-dev, as well as the dependencies, there should be a dependency on a library package which should provide the libOpenCL.so.1.0.0 file.

            – QIS
            2 days ago















            0














            I managed to solve this, so I am posting what I did in case anybody falls in the same pit.



            First of all, I did have a broken symlink here:



            $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
            lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


            I had OpenCL installed via the Intel SDK for OpenCL Applications, and I had messed things up with the installation a little.



            What I found after some digging is that the Intel SDK installation installs the OpenCL shared libraries -having in mind changes in year and versions- in /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/.
            For my system (Linux Mint), this is the default location (the only thing you can change during the installation is /opt/intel/). In fact, it looks something like this:



            $ ls -l /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/ | grep libOpenCL
            lrwxrwxrwx 1 root root 16 Aug 16 04:35 libOpenCL.so -> ./libOpenCL.so.1
            lrwxrwxrwx 1 root root 18 Aug 16 04:35 libOpenCL.so.1 -> ./libOpenCL.so.2.0
            -rwxr-xr-x 1 root root 48216 Sep 21 2018 libOpenCL.so.2.0


            This means that the only "actual" file is libOpenCL.so.2.0 and there is a train of symlinks: libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0.



            Furthermore, I found out that there is a number of symlinks in /etc/alternatives/, that look quite OK (basically, what I understood is that they resolve the number at the end of the library name and serve as a middleman in case something changes at the actual libraries - which are all the same in my system, as I pointed out before):



            $ ls -l /etc/alternatives/ | grep OpenCL
            lrwxrwxrwx 1 root root 115 Aug 16 04:35 opencl-libOpenCL.so -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so
            lrwxrwxrwx 1 root root 117 Aug 16 04:35 opencl-libOpenCL.so.1 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1
            lrwxrwxrwx 1 root root 119 Aug 16 04:35 opencl-libOpenCL.so.2.0 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0


            So, the simplest thing I could do was to completely remove the broken symlink above (just rm) and create 3 new symlinks, one for each number at the end of the library name, just to be sure:



            $ cd /usr/lib/x86_64-linux-gnu
            $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so libOpenCL.so
            $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.1 libOpenCL.so.1
            $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.2.0 libOpenCL.so.2.0


            Now, the /usr/lib/x86_64-linux-gnu directory looks like this and everything seems to work:



            $ ls -l /usr/lib/x86_64-linux-gnu/ | grep OpenCL
            lrwxrwxrwx 1 root root 37 Aug 16 04:47 libOpenCL.so -> /etc/alternatives/opencl-libOpenCL.so
            lrwxrwxrwx 1 root root 39 Aug 16 04:47 libOpenCL.so.1 -> /etc/alternatives/opencl-libOpenCL.so.1
            lrwxrwxrwx 1 root root 41 Aug 16 04:35 libOpenCL.so.2.0 -> /etc/alternatives/opencl-libOpenCL.so.2.0





            share|improve this answer








            New contributor



            Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.


























              0














              I managed to solve this, so I am posting what I did in case anybody falls in the same pit.



              First of all, I did have a broken symlink here:



              $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
              lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


              I had OpenCL installed via the Intel SDK for OpenCL Applications, and I had messed things up with the installation a little.



              What I found after some digging is that the Intel SDK installation installs the OpenCL shared libraries -having in mind changes in year and versions- in /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/.
              For my system (Linux Mint), this is the default location (the only thing you can change during the installation is /opt/intel/). In fact, it looks something like this:



              $ ls -l /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/ | grep libOpenCL
              lrwxrwxrwx 1 root root 16 Aug 16 04:35 libOpenCL.so -> ./libOpenCL.so.1
              lrwxrwxrwx 1 root root 18 Aug 16 04:35 libOpenCL.so.1 -> ./libOpenCL.so.2.0
              -rwxr-xr-x 1 root root 48216 Sep 21 2018 libOpenCL.so.2.0


              This means that the only "actual" file is libOpenCL.so.2.0 and there is a train of symlinks: libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0.



              Furthermore, I found out that there is a number of symlinks in /etc/alternatives/, that look quite OK (basically, what I understood is that they resolve the number at the end of the library name and serve as a middleman in case something changes at the actual libraries - which are all the same in my system, as I pointed out before):



              $ ls -l /etc/alternatives/ | grep OpenCL
              lrwxrwxrwx 1 root root 115 Aug 16 04:35 opencl-libOpenCL.so -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so
              lrwxrwxrwx 1 root root 117 Aug 16 04:35 opencl-libOpenCL.so.1 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1
              lrwxrwxrwx 1 root root 119 Aug 16 04:35 opencl-libOpenCL.so.2.0 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0


              So, the simplest thing I could do was to completely remove the broken symlink above (just rm) and create 3 new symlinks, one for each number at the end of the library name, just to be sure:



              $ cd /usr/lib/x86_64-linux-gnu
              $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so libOpenCL.so
              $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.1 libOpenCL.so.1
              $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.2.0 libOpenCL.so.2.0


              Now, the /usr/lib/x86_64-linux-gnu directory looks like this and everything seems to work:



              $ ls -l /usr/lib/x86_64-linux-gnu/ | grep OpenCL
              lrwxrwxrwx 1 root root 37 Aug 16 04:47 libOpenCL.so -> /etc/alternatives/opencl-libOpenCL.so
              lrwxrwxrwx 1 root root 39 Aug 16 04:47 libOpenCL.so.1 -> /etc/alternatives/opencl-libOpenCL.so.1
              lrwxrwxrwx 1 root root 41 Aug 16 04:35 libOpenCL.so.2.0 -> /etc/alternatives/opencl-libOpenCL.so.2.0





              share|improve this answer








              New contributor



              Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.
























                0












                0








                0







                I managed to solve this, so I am posting what I did in case anybody falls in the same pit.



                First of all, I did have a broken symlink here:



                $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
                lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


                I had OpenCL installed via the Intel SDK for OpenCL Applications, and I had messed things up with the installation a little.



                What I found after some digging is that the Intel SDK installation installs the OpenCL shared libraries -having in mind changes in year and versions- in /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/.
                For my system (Linux Mint), this is the default location (the only thing you can change during the installation is /opt/intel/). In fact, it looks something like this:



                $ ls -l /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/ | grep libOpenCL
                lrwxrwxrwx 1 root root 16 Aug 16 04:35 libOpenCL.so -> ./libOpenCL.so.1
                lrwxrwxrwx 1 root root 18 Aug 16 04:35 libOpenCL.so.1 -> ./libOpenCL.so.2.0
                -rwxr-xr-x 1 root root 48216 Sep 21 2018 libOpenCL.so.2.0


                This means that the only "actual" file is libOpenCL.so.2.0 and there is a train of symlinks: libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0.



                Furthermore, I found out that there is a number of symlinks in /etc/alternatives/, that look quite OK (basically, what I understood is that they resolve the number at the end of the library name and serve as a middleman in case something changes at the actual libraries - which are all the same in my system, as I pointed out before):



                $ ls -l /etc/alternatives/ | grep OpenCL
                lrwxrwxrwx 1 root root 115 Aug 16 04:35 opencl-libOpenCL.so -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so
                lrwxrwxrwx 1 root root 117 Aug 16 04:35 opencl-libOpenCL.so.1 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1
                lrwxrwxrwx 1 root root 119 Aug 16 04:35 opencl-libOpenCL.so.2.0 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0


                So, the simplest thing I could do was to completely remove the broken symlink above (just rm) and create 3 new symlinks, one for each number at the end of the library name, just to be sure:



                $ cd /usr/lib/x86_64-linux-gnu
                $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so libOpenCL.so
                $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.1 libOpenCL.so.1
                $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.2.0 libOpenCL.so.2.0


                Now, the /usr/lib/x86_64-linux-gnu directory looks like this and everything seems to work:



                $ ls -l /usr/lib/x86_64-linux-gnu/ | grep OpenCL
                lrwxrwxrwx 1 root root 37 Aug 16 04:47 libOpenCL.so -> /etc/alternatives/opencl-libOpenCL.so
                lrwxrwxrwx 1 root root 39 Aug 16 04:47 libOpenCL.so.1 -> /etc/alternatives/opencl-libOpenCL.so.1
                lrwxrwxrwx 1 root root 41 Aug 16 04:35 libOpenCL.so.2.0 -> /etc/alternatives/opencl-libOpenCL.so.2.0





                share|improve this answer








                New contributor



                Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                I managed to solve this, so I am posting what I did in case anybody falls in the same pit.



                First of all, I did have a broken symlink here:



                $ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
                lrwxrwxrwx 1 root root 18 Dec 18 2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0


                I had OpenCL installed via the Intel SDK for OpenCL Applications, and I had messed things up with the installation a little.



                What I found after some digging is that the Intel SDK installation installs the OpenCL shared libraries -having in mind changes in year and versions- in /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/.
                For my system (Linux Mint), this is the default location (the only thing you can change during the installation is /opt/intel/). In fact, it looks something like this:



                $ ls -l /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/ | grep libOpenCL
                lrwxrwxrwx 1 root root 16 Aug 16 04:35 libOpenCL.so -> ./libOpenCL.so.1
                lrwxrwxrwx 1 root root 18 Aug 16 04:35 libOpenCL.so.1 -> ./libOpenCL.so.2.0
                -rwxr-xr-x 1 root root 48216 Sep 21 2018 libOpenCL.so.2.0


                This means that the only "actual" file is libOpenCL.so.2.0 and there is a train of symlinks: libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0.



                Furthermore, I found out that there is a number of symlinks in /etc/alternatives/, that look quite OK (basically, what I understood is that they resolve the number at the end of the library name and serve as a middleman in case something changes at the actual libraries - which are all the same in my system, as I pointed out before):



                $ ls -l /etc/alternatives/ | grep OpenCL
                lrwxrwxrwx 1 root root 115 Aug 16 04:35 opencl-libOpenCL.so -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so
                lrwxrwxrwx 1 root root 117 Aug 16 04:35 opencl-libOpenCL.so.1 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1
                lrwxrwxrwx 1 root root 119 Aug 16 04:35 opencl-libOpenCL.so.2.0 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0


                So, the simplest thing I could do was to completely remove the broken symlink above (just rm) and create 3 new symlinks, one for each number at the end of the library name, just to be sure:



                $ cd /usr/lib/x86_64-linux-gnu
                $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so libOpenCL.so
                $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.1 libOpenCL.so.1
                $ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.2.0 libOpenCL.so.2.0


                Now, the /usr/lib/x86_64-linux-gnu directory looks like this and everything seems to work:



                $ ls -l /usr/lib/x86_64-linux-gnu/ | grep OpenCL
                lrwxrwxrwx 1 root root 37 Aug 16 04:47 libOpenCL.so -> /etc/alternatives/opencl-libOpenCL.so
                lrwxrwxrwx 1 root root 39 Aug 16 04:47 libOpenCL.so.1 -> /etc/alternatives/opencl-libOpenCL.so.1
                lrwxrwxrwx 1 root root 41 Aug 16 04:35 libOpenCL.so.2.0 -> /etc/alternatives/opencl-libOpenCL.so.2.0






                share|improve this answer








                New contributor



                Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.








                share|improve this answer



                share|improve this answer






                New contributor



                Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.








                answered 2 days ago









                ZehanortZehanort

                11 bronze badge




                11 bronze badge




                New contributor



                Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.




                New contributor




                Zehanort is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.



























                    Zehanort is a new contributor. Be nice, and check out our Code of Conduct.










                    draft saved

                    draft discarded


















                    Zehanort is a new contributor. Be nice, and check out our Code of Conduct.













                    Zehanort is a new contributor. Be nice, and check out our Code of Conduct.












                    Zehanort is a new contributor. Be nice, and check out our Code of Conduct.
















                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f535805%2ffailed-to-load-library-libopencl-so-1-although-it-exists%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

                    Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

                    Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...