Building frustration (on Oracle Linux, solved)

[Raffaello Giulietti]

On 2015-12-27 20:30, Doug Simon wrote:
> 
>> On 27 Dec 2015, at 15:52, Raffaello Giulietti <raffaello.giulietti at supsi.ch> wrote:
>>
>> On 2015-12-27 12:48, Doug Simon wrote:
>>>>>> I dislike Ubuntu for other reasons not related to Truffle/Graal.
>>>>>> However, I have to admit that, at least for the purpose of building
>>>>>> Truffle/Graal and for working on it, it was much smoother an experience
>>>>>> than with CentOS, Fedora and Oracle Linux, all of them I tried before.
>>>>>> Hence, I think I’ll stick with it.
>>>>>
>>>>> Strange, I would not expect much differences with those distributions either.
>>>>> Not sure what the counter part of build-essentials is, but it shouldn’t be much more than a C/C++ tool chain, and some development headers (see http://packages.ubuntu.com/trusty/build-essential).
>>>>>
>>>>> I was under the impression that some of us use Oracle Linux to work on Graal. Perhaps we could extend the instructions for those distributions. Do you remember any of the specific issues you ran into?
>>>>>
>>>>
>>>> Since I don't remember the details, I would have to retry the
>>>> installation. I run my Linux systems as VirtualBox images, so that
>>>> should be possible with little investment in time starting from scratch,
>>>> i.e., by first installing the OS (for what it costs, VirtualBox is
>>>> really a great product). No promises, however...
>>>>
>>
>> As *not* promised, I retried a build of Truffle/Graal on a freshly
>> installed Oracle Linux 7.2. For the installation I chose the "Server
>> with GUI" software selection with the "Development Tools" among other
>> packages. Immediately after installation, I updated everything proposed
>> by the "Software Update" system tool.
>>
>> I then proceeded by installing the ant, hg and Oracle JDK 8 packages.
>>
>> While following the instructions at
>> https://wiki.openjdk.java.net/display/Graal/Instructions, the build
>> stops with the following messages:
>>
>> --------
>> Linking vm...
>> /usr/bin/ld: cannot find -lstdc++
>>
>> collect2: error: ld returned 1 exit status
>>
>> /usr/bin/chcon: cannot access ‘libjvm.so’: No such file or directory
>>
>> ERROR: Cannot chcon libjvm.so
>> /usr/bin/objcopy: 'libjvm.so': No such file
>> --------
>>
>> Of course, some version of libstdc++.so.* exists in /usr/lib64 but there
>> is no unqualified libstdc++.so link. I'm not sure if this is needed, if
>> it has been forgotten, if it depends on some configuration that I miss.
>>
>> Even after creating a libstdc++.so -> libstdc++.so.6 link in /usr/lib64,
>> the above error message still persists. Afaik, this folder needs not to
>> appear on LD_LIBRARY_PATH (which I didn't care to set in the first
>> place, since it's not needed on Ubuntu).
>>
>> I hope I'm such an idiot to have forgotten something trivial.
> 
> No, you’re absolutely not. I ran into the same issue recently when I obtained a VM running "Oracle Linux 7 u1”. The problem is that the HotSpot build system wants to statically link in the stdc++ library and (in my case at least), there is no static version of libstdc++. That is, there is no libstdc++*.a files next to the libstdc++.so* files. My solution was to patch the relevant HotSpot make file to enable dynamic linking of the C++ library:
> 


After your note about the static version of the library, I found the
right and "official" package at
http://public-yum.oracle.com/repo/OracleLinux/OL7/optional/latest/x86_64/index.html

I just downloaded
http://public-yum.oracle.com/repo/OracleLinux/OL7/optional/latest/x86_64/getPackage/libstdc++-static-4.8.5-4.el7.x86_64.rpm
on the hard-drive and installed it from there. My yum cannot find it in
the standard repositories but I didn't reconfigure them.

After this, the build proceeds successfully.

I think this solution is cleaner than a patch in the makefile. Maybe it
is something worth documenting somewhere.


Greetings
Raffaello