solves CXXABI_1.3.8 not found on ubuntu14 and centos7

[zhuker]

since linux jocl library is built on ubuntu/xenial it uses newer cxxabi, when i am trying to run my code on centos7 or ubuntu14 which do not have cxxabi1.3.8 i get this:

java.lang.UnsatisfiedLinkError: /tmp/libJOCL_2_0_0-linux-x86_64.so: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/libJOCL_2_0_0-linux-x86_64.so)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
        at java.lang.Runtime.load0(Runtime.java:809)
        at java.lang.System.load(System.java:1086)
        at org.jocl.LibUtils.loadLibraryResource(LibUtils.java:269)
        at org.jocl.LibUtils.loadLibrary(LibUtils.java:151)
        at org.jocl.CL.loadNativeLibrary(CL.java:65)
        at org.jocl.CL.<clinit>(CL.java:51)

this PR solves this problem by running vagrant build on centos7

[gpu]

Thanks for that. I'm not deeply familiar with the versioning constraints and the particular library that this is about.

But if I understood this correctly, then this just causes a library with a lower version number to be used as a dependency. If this is right, I'll certainly pull it. I think it's a good rule of thumb to use the "lowest version number that is possible" for any dependency (unless there are compelling reasons not to do so).

I'll try it out ASAP with a fresh Vagrant machine (although I cannot thoroughly test the resulting library, of course). It may take a few days, there are some other, higher priority tasks in the queue right now.

Thanks again!

[zhuker]

this just causes a library with a lower version number to be used as a dependency.

same version of library lower ABI level so even better

[zhuker]

@gpu bump up

[gpu]

Sorry for the delay here. And I have to admit that this PR might have been buried under all my other tasks, so thanks for the bump as well.

I've tried it out, and it seems to work, basically.

What I'm wondering about: Why is it necessary to install the scp plugin? I'd prefer to just copy the files to the host directly. But it seems like the host directory is no longer synced with the /vagrant directory. There didn't seem to be anything related to that in the Vagrantfile. (And adding a config.vm.synced_folder ".", "/vagrant" did not make a difference - it should be the default, anyhow).

Do you know what the reason for this is, or how to allow the syncing so that the plugin is not required?

[zhuker]

I honestly don't know. It's the first time I was using vagrant. Just made it work - it is possibly not the most optimal way.

On Sun, Apr 29, 2018, 14:06 Marco Hutter notifications@github.com wrote:

Sorry for the delay here. And I have to admit that this PR might have been buried under all my other tasks, so thanks for the bump as well.

I've tried it out, and it seems to work, basically.

What I'm wondering about: Why is it necessary to install the scp plugin? I'd prefer to just copy the files to the host directly. But it seems like the host directory is no longer synced with the /vagrant directory. There didn't seem to be anything related to that in the Vagrantfile. (And adding a config.vm.synced_folder ".", "/vagrant" did not make a difference - it should be the default, anyhow).

Do you know what the reason for this is, or how to allow the syncing so that the plugin is not required?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gpu/JOCL/pull/22#issuecomment-385250191, or mute the thread https://github.com/notifications/unsubscribe-auth/AEKlQlboJnRGHLLot9CxQnAW7BYTfH6sks5ttbq5gaJpZM4TCbUC .

[gpu]

Well, except for that point, it seemed to work quite well, and my gut feeling is that this can only be a subtle detail - again,the host directory should be mapped to /vagrant by default - I'll try to figure out why this does not happen ASAP.

[zhuker]

sorry to bother

[gpu]

You're not bothering me. I have to apologize for the delay here (and to admit that this had a little lower priority than other tasks).

I read a bit about the mapping of the host directory into the virtual machine, and it seems that this was caused by a mix of a missing part in the config and an outdated VirtualBox version that I was using, as well as a missing "Guest Additions" plugin for vagrant. (BTW: Maybe you already had installed this plugin?)

I have updated the Vagrantfile based on your PR, and extended the README with some version information.

(I'll close this PR, because I had to modify the Vagrantfile a bit, but it is essentially the one that you provided. I also added acknowledgements at https://github.com/gpu/JOCL#building-on-a-virtual-machine )

Thanks again for your contribution!

[zhuker]

@gpu can you build a new release ? 2.0.1?

[gpu]

One minor issue here is that there's currently no contributor for the MacOS libraries.

Maybe @milikicn can provide them? (He did provide the JOCLBlast binaries - there's still an issue with them, but this seems to be specific for CLBlast)

Apart from that, I could schedule a new release.

[zhuker]

i am actually interested to support macos as well (i develop my software on mac and run it on centos) is there anything specific to consider?

[gpu]

Actually, in some sense, it may not even be necessary to re-build the MacOS binaries: They should not have changed since version 2.0.0.

But for the sake of a clean process, I'll create a tag v2.0.1, and re-build the release from this tag.

I'll drop you a note here when everything is ready.

Apart from that: The process should be straightforward: CMake+make (as described in the README) should do the job.

(If this is not the case, then this would be something to be tackled anyhow)

[zhuker]

yeah macos binaries should stay the same from 2.0.0

[milikicn]

@gpu I built the project, but then I have realized they have the 2.0.0 version number as you have mentioned. Let me know when you need building OS X libraries for future versions.

[zhuker]

Ok. Are you good to release 2.0.1 now?

On Tue, May 29, 2018, 10:07 Nikola Milikic notifications@github.com wrote:

@gpu https://github.com/gpu I built the project, but then I have realized they have the 2.0.0 version number as you have mentioned. Let me know when you need building OS X libraries for future versions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gpu/JOCL/pull/22#issuecomment-392674334, or mute the thread https://github.com/notifications/unsubscribe-auth/AEKlQutyntYkyy-rpfW7UQhJpUfaeZGuks5t3POlgaJpZM4TCbUC .

[gpu]

I have updated the version numbers and created a tag at https://github.com/gpu/JOCL/releases/tag/jocl-2.0.1-RC00. This can be used to build the native libraries. I can create that for Win/Linux (the latter using the Vagrant machine). If you could provide the one for MacOS, I'll schedule the Maven release ASAP.

[milikicn]

@gpu these are the libraries for the OS X (.dylib was renamed to .zip)

libJOCL_2_0_1-apple-x86_64.zip

[gpu]

Thanks. I'm currently preparing the release, and noticed that the current description of the build process with Vagrant does not work. There is something wrong with the Guest Additions and Folder Syncing. After all, the idea of having a build process on a VM is rendered useless when setting up the VM properly is more complicated than the "manual" build process, but however, I'll reopen this one and see if I can (and/or want to) allocate time to fix this.

[gpu]

The PR may not be the right place, I have opened https://github.com/gpu/JOCL/issues/23

[gpu]

Version 2.0.1 has been released, and is available at

<dependency>
    <groupId>org.jocl</groupId>
    <artifactId>jocl</artifactId>
    <version>2.0.1</version>
</dependency>