Seismic issueshttps://community.opengroup.org/groups/osdu/platform/domain-data-mgmt-services/seismic/-/issues2023-06-13T20:05:35Zhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/94Info endpoint is missed2023-06-13T20:05:35ZDenis Karpenok (EPAM)Info endpoint is missedcurl --location --request GET 'https://preship.gcp.gnrg-osdu.projects.epam.com/api/seismic-store/v3/info'
Response:
[seismic-store-service] Unauthenticated Access. Authorizations not found in the request.
With authentication response ...curl --location --request GET 'https://preship.gcp.gnrg-osdu.projects.epam.com/api/seismic-store/v3/info'
Response:
[seismic-store-service] Unauthenticated Access. Authorizations not found in the request.
With authentication response is:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /api/v3/info</pre>
</body>
</html>
Expected:
Version is returning without authentication.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-sdutil/-/issues/13Ingest of multi-object, cloud-optimized formats into Seismic DDMS2023-03-30T16:52:43ZGregIngest of multi-object, cloud-optimized formats into Seismic DDMSIngest of multi-object, cloud-optimized formats into Seismic DDMS
a. The sdutil utility can be used to create a seismic dataset within an associated, already created seismic project, but only if the seismic dataset includes exactly one ...Ingest of multi-object, cloud-optimized formats into Seismic DDMS
a. The sdutil utility can be used to create a seismic dataset within an associated, already created seismic project, but only if the seismic dataset includes exactly one object. It isn’t currently possible to use sdutil to create a seismic dataset comprising an object-store optimized dataset--FileCollection.Bluware.OpenVDS:1.0.0, even if the FileCollection already exists in another object store location or on a local file system.
b. An existing ingest flow provided in the R3M7 release can be used to generate and create a seismic dataset that comprises a dataset--FileCollection.Bluware.OpenVDS:1.0.0, but only if:
i. The ingested source is in segy format
ii. The conversion from segy to OpenVDS S3 format occurs in a container hosted within the data platformChris ZhangChris Zhanghttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/8Integration tests assume a valid legal tag exists2023-03-27T19:30:52ZRucha DeshpandeIntegration tests assume a valid legal tag existsIf the FEATURE FLAG for legal is set to true, it checks the validity of the legal tag passed in 'ltag'.If the FEATURE FLAG for legal is set to true, it checks the validity of the legal tag passed in 'ltag'.Rucha DeshpandeDiego MolteniRucha Deshpandehttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/127Issue with Get Status API2024-02-09T18:12:56ZJiman KimIssue with Get Status APIHello we are running some authentication testing and are running into some behaviors that may or may not be a bug.
for this endpoint
/seistore-svc/api/v4/status
We have 3 tests running
1. Sends an invalid token
2. Sends a valid toke...Hello we are running some authentication testing and are running into some behaviors that may or may not be a bug.
for this endpoint
/seistore-svc/api/v4/status
We have 3 tests running
1. Sends an invalid token
2. Sends a valid token but signed with a wrong secret
3. Sends the HTTP request without an authorization header.
1,2 return a 401
but 3 returns 200.
Is this a bug or intended behavior?
Thank you!M21 - Release 0.24https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/172KnownChannelNames class2023-02-23T12:36:51ZMorten OfstadKnownChannelNames classThere should be a KnownChannelNames class with the names from the documentation (https://osdu.pages.opengroup.org/platform/domain-data-mgmt-services/seismic/open-vds/vds/specification/Metadata.html#named-channels) -- For C++ this is foun...There should be a KnownChannelNames class with the names from the documentation (https://osdu.pages.opengroup.org/platform/domain-data-mgmt-services/seismic/open-vds/vds/specification/Metadata.html#named-channels) -- For C++ this is found in GlobalMetadataCommon.h, but it is not available in Python/Java.Morten OfstadMorten Ofstadhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/101Long running query (in Azure) is not cancelled2023-08-07T14:27:49ZLaura DamianLong running query (in Azure) is not cancelledSteps to reproduce:
- try to retrieve datasets in a folder with more than 1M datasets
- cancel the request or wait for timeout in the typescript code
- check the "Total Request Units" in CosmosDB metrics. These do not decrease.
Sugge...Steps to reproduce:
- try to retrieve datasets in a folder with more than 1M datasets
- cancel the request or wait for timeout in the typescript code
- check the "Total Request Units" in CosmosDB metrics. These do not decrease.
Suggestions:
- Add an explicit timeout in the typescript code for the calls to the sidecar.
- Add a cancellation token in the sidecar's endpoints and propagate them to CosmosDBMax ZeierLaura DamianKonstantin GukovMax Zeierhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/65Make cloud interfaces and abstract classes less GCP specific2023-03-24T19:13:34ZYan Sushchynski (EPAM)Make cloud interfaces and abstract classes less GCP specificHello!
During implementing `Anthos` provider we faced troubles with creating the concrete `Journal` class: [here](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/...Hello!
During implementing `Anthos` provider we faced troubles with creating the concrete `Journal` class: [here](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/blob/feat/Anthos_GCP/app/sdms/src/cloud/providers/anthos/postgresql.ts#L96).
If we understand correctly, `AbstractJournal` and `AbstractJournalTransaction` classes simply reproduce GCP Datastore interfaces. It is ok for GCP implementation, because there is no extra effort needed for implementing concrete journal classes. However, it is hard to implement concrete journal classes for other CSPs. This becomes obvious when we compare the number of lines for GCP and other CSPs particular journal classes (e.g., [GCP](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/blob/feat/Anthos_GCP/app/sdms/src/cloud/providers/google/datastore.ts) and [Azure](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/blob/feat/Anthos_GCP/app/sdms/src/cloud/providers/azure/cosmosdb.ts)).
Also, using Datastore "low-level" logic in the core code makes this code hard to read and debug. E.g., for Anthos we use PostgreSQL database and the concrete implementation required a lot of workarounds to fit Datastore "low-level" methods into SQL.
For example, there are specific Datastore operators in the abstract class ([here](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/blob/feat/Anthos_GCP/app/sdms/src/cloud/journal.ts#L25)).
I'd suggest refactoring the common code and switch from using Datastore methods to focusing on more general and high-level logic.
For example, instead of using [this](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/blob/master/app/sdms/src/services/dataset/dao.ts#L46) in the common code
```ts
let query = journalClient.createQuery(
Config.SEISMIC_STORE_NS + '-' + dataset.tenant + '-' + dataset.subproject, Config.DATASETS_KIND);
query = query.filter('name', dataset.name).filter('path', dataset.path);
const [entities] = await journalClient.runQuery(query);
```
We could use something like this:
```ts
// Just an example
const entity = await journalClient.getEntity(dataset.path, dataset.name);
```
In this case, we could be more concise and cleaner in concrete CSP implementations. Also, implementing high-level classes lets us use the best practices for each particular data base.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/28Make it possible to set ActualValueRange during import2023-09-21T10:03:08ZMorten OfstadMake it possible to set ActualValueRange during importCurrently the VolumeDataLayout is immutable so there is no way to update the ActualValueRange once it's known (after importing all the data). In order for this to work there needs to be a setter for the ActualValueRange, a dirty-flag for...Currently the VolumeDataLayout is immutable so there is no way to update the ActualValueRange once it's known (after importing all the data). In order for this to work there needs to be a setter for the ActualValueRange, a dirty-flag for the layout and code to re-upload the layout if it is dirty when committing.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/147Nearest interpolation does not choose the numerically nearest voxel2023-10-19T18:24:41ZErlend HårstadNearest interpolation does not choose the numerically nearest voxel
Hi,
Why does vds’ nearest interpolation interpolate in the range `[0, 1)` in around voxels, and not `[-0.5, 0.5)`? I find this a bit surprising. If I ask for voxel 1.99 in some dimension I would expect to get voxel 2 not 1, as 2 is nume...
Hi,
Why does vds’ nearest interpolation interpolate in the range `[0, 1)` in around voxels, and not `[-0.5, 0.5)`? I find this a bit surprising. If I ask for voxel 1.99 in some dimension I would expect to get voxel 2 not 1, as 2 is numerically “nearer” to 1.99 than 1https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-zgy/-/issues/18.NET bindings2021-06-24T10:14:51ZRobert Schmidt.NET bindingsWe ([Cegal](https://cegal.com/)) have a branch with basic C and .NET bindings to the (new) OpenZGY API.
- netstandard2.0, with xunit tests and a console app for net5.0
- Capable of building Debug and Release nuget packages
- Console app...We ([Cegal](https://cegal.com/)) have a branch with basic C and .NET bindings to the (new) OpenZGY API.
- netstandard2.0, with xunit tests and a console app for net5.0
- Capable of building Debug and Release nuget packages
- Console app can dump ZGY meta data, copy and compare ZGY content
- Windows only for now (I would need assistance for Linux support)
- Seismic Store support - sdapi binaries and headers are added to branch
- 2 source files are added to OpenZGY.vcxproj to provide the C bindings, no changes to existing code
- Bindings expose a simplified API for now (e.g. no compression or const support)
Would this be of interest for this repo?
Until more complete, it should probably live as a separate branch.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-cpp-lib/-/issues/19New versions does not support m11 release or older2023-03-30T16:33:04ZJørgen Lindjorgen.lind@3lc.aiNew versions does not support m11 release or olderIt seems that new versions of seismic-dms-cpp-lib does not support m11 release giving the error message:
`sdapi 3.16.0 - SeismicStore::DatasetRegister: Error executing an HTTP request [ HTTP 404 ]`It seems that new versions of seismic-dms-cpp-lib does not support m11 release giving the error message:
`sdapi 3.16.0 - SeismicStore::DatasetRegister: Error executing an HTTP request [ HTTP 404 ]`https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-sdutil/-/issues/28No errors/warnings reported when uploading seismic file with corrupted blocks2023-08-18T15:15:16ZMichaelNo errors/warnings reported when uploading seismic file with corrupted blocksI uploaded a segy file to seismic ddms for the AZURE pre shipping using sdutil and no errors/warnings were reported.
Later, when trying to read the segy file using the sdapi library, there were unreadable blocks. I re-uploaded the file ...I uploaded a segy file to seismic ddms for the AZURE pre shipping using sdutil and no errors/warnings were reported.
Later, when trying to read the segy file using the sdapi library, there were unreadable blocks. I re-uploaded the file to a different sd path and I got MD5 checksum errors when trying to read the block.
we tried to upload the file to the following locations:
sd://opendes/michaelm19/cdp_stack.sgy: the last block of this file (22) was unreadable
sd://opendes/michaelm19/cdp_stack_from_q.sgy : the blocks 3, 6, 9, and 13 have checksum errors
The original file can be accessed here: https://osdutroubleshootingfiles.s3.us-east-2.amazonaws.com/cdp_stack.sgy
Our Concern is that sdutil did not report any errors when the results of the file uploading is corrupted.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/143No README.md for HueBDS2022-09-13T12:25:25ZMorten OfstadNo README.md for HueBDSThere is no README.md for the HueBDS tool and it doesn't get an entry in the documentation.There is no README.md for the HueBDS tool and it doesn't get an entry in the documentation.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/159Online Python documentation incomplete2022-11-21T09:34:46ZAlexander JaustOnline Python documentation incompleteIt seems that the online documentation of the Python interface is incomplete. I did not go through everything, but I found the following inconsistencies and problems.
Would it be possible to expose more documentation on the homepage? I ...It seems that the online documentation of the Python interface is incomplete. I did not go through everything, but I found the following inconsistencies and problems.
Would it be possible to expose more documentation on the homepage? I am not sure if some documentation is simply missing or not generated on purpose. In all cases that I have checked the classes and methods have a documentation accessible via Python's `help(...)` function.
## Observations
### VolumeDataLayoutDescriptor
I do not find anything about the constructors of `class VolumeDataLayoutDescriptor` in the [online documentation](https://osdu.pages.opengroup.org/platform/domain-data-mgmt-services/seismic/open-vds/python-api.html#openvds.VolumeDataLayoutDescriptor). When I query the documentation via Python I get much more information including the constructor.
That means if I do the following in a Python session
```text
import openvds
help(openvds.VolumeDataLayoutDescriptor)
```
gives the following (shortened) output
```text
Help on class VolumeDataLayoutDescriptor in module openvds.core:
class VolumeDataLayoutDescriptor(pybind11_builtins.pybind11_object)
| Method resolution order:
| VolumeDataLayoutDescriptor
| pybind11_builtins.pybind11_object
| builtins.object
|
| Methods defined here:
|
| __init__(...)
| __init__(*args, **kwargs)
| Overloaded function.
|
| 1. __init__(self: openvds.core.VolumeDataLayoutDescriptor) -> None
|
| 2. __init__(self: openvds.core.VolumeDataLayoutDescriptor, brickSize: OpenVDS::VolumeDataLayoutDescriptor::BrickSize, negativeMargin: int, positiveMargin: int, brickSize2DMultiplier: int, lodLevels: OpenVDS::VolumeDataLayoutDescriptor::LODLevels, options: OpenVDS::VolumeDataLayoutDescriptor::Options, fullResolutionDimension: int = 0) -> None
|
...
```
As you can see there is some information on the constructor.
### VolumeDataRequest
There are (at least?) two types of `VolumeDataRequest`, but only one is documented in the [online documentation](https://osdu.pages.opengroup.org/platform/domain-data-mgmt-services/seismic/open-vds/python-api.html#openvds.VolumeDataRequest).
The documentation explains the usage of an object of type `openvds.core.VolumeDataRequest`, see
```text
>>> import openvds
>>> data_request = openvds.VolumeDataRequest
>>> print(data_request)
<class 'openvds.core.VolumeDataRequest'>
>>> buffer = data_request.buffer
>>> data = data_request.data
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: type object 'openvds.core.VolumeDataRequest' has no attribute 'data'
```
This class does not have any attribute called `data` so the error is correct.
However, a function call to the function `requestVolumeSubset` of a `VolumeDataAccessManager` will return an object of type `openvds.volumedataaccess.VolumeDataRequest` with different interface which has a property called `data` instead of `buffer`.
```text
>>> import openvds
>>> data_request = openvds.volumedataaccess.VolumeDataRequest
>>> print(data_request)
<class 'openvds.volumedataaccess.VolumeDataRequest'>
>>> buffer = data_request.buffer
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: type object 'VolumeDataRequest' has no attribute 'buffer'
>>> data = data_request.data
```
This class does not have a `buffer` attribute so the error message is fine. It is not clear from the documentation of [`VolumeDataAccessManager`](https://osdu.pages.opengroup.org/platform/domain-data-mgmt-services/seismic/open-vds/python-api.html#id59) that the return type is not a `openvds.core.VolumeDataRequest`.
### openvds.IJKCoordinateTransformer
There is no documentation on the `IJKCoordinateTransformer` for Python even though it is accessible from Python
```text
>>> transformer = openvds.IJKCoordinateTransformer
>>> print(transformer)
<class 'openvds.core.IJKCoordinateTransformer'>
```
### VolumeDataAccessManager
The type annotation for the constructor of the `handle` seems to be off as it is `int`, but should be `openvds.core.VDS`.
```text
>>> vdam = openvds.VolumeDataAccessManager
>>> print(vdam)
<class 'openvds.volumedataaccess.VolumeDataAccessManager'>
>>> vdam = openvds.VolumeDataAccessManager(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/aej/software/openvds-3.0.3-install-python/python/openvds/volumedataaccess.py", line 184, in __init__
self._manager = openvds.core.getAccessManager(handle)
TypeError: getAccessManager(): incompatible function arguments. The following argument types are supported:
1. (handle: openvds.core.VDS) -> OpenVDS::VolumeDataAccessManager
Invoked with: 1
```
Update: In the last case, supplying an object of type `openvds.core.VDS` also fails so I assume the documentation might be off here or I misunderstand something.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/86osdu:wks:work-product-component--NotionalSeismicLine:1.0.02023-03-24T15:58:23ZSacha Brantsosdu:wks:work-product-component--NotionalSeismicLine:1.0.0https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/98Pagination not supported by IBM and AWS for DATASET LIST (POST) endpoint2023-04-05T14:28:58ZPratiksha ShedgePagination not supported by IBM and AWS for DATASET LIST (POST) endpointA new API has been added as DATASET LIST (POST) endpoint which supports pagination. This API should return the list of datasets and nextPageCursor to get the next list of datasets. However, IBM and AWS do not support pagination for this ...A new API has been added as DATASET LIST (POST) endpoint which supports pagination. This API should return the list of datasets and nextPageCursor to get the next list of datasets. However, IBM and AWS do not support pagination for this endpoint, which causes the pagination tests to fail during pipeline runs.
Pipeline runs:
IBM-https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/jobs/1823012
AWS-https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/jobs/1842803https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/125Patch dataset name issue2024-01-22T16:21:23ZYan Sushchynski (EPAM)Patch dataset name issueWe ran the [collection](https://community.opengroup.org/osdu/platform/pre-shipping/-/blob/main/R3-M22/GC-M22/GC_OSDU_Smoke_Tests.postman_collection.json?ref_type=heads), and this request
```bash
curl --location --request PATCH 'https:/...We ran the [collection](https://community.opengroup.org/osdu/platform/pre-shipping/-/blob/main/R3-M22/GC-M22/GC_OSDU_Smoke_Tests.postman_collection.json?ref_type=heads), and this request
```bash
curl --location --request PATCH 'https://<host>/api/seismic-store/v3/dataset/tenant/m19/subproject/subprojectodi374308/dataset/AutoTest_dsetodi831125?path=autotest_path' \
--header 'Content-Type: application/json' \
--header 'data-partition-id: m19' \
--header 'Authorization: Bearer token' \
--data '{
"dataset_new_name": "autotest_new",
"metadata": {
"f1": "v1",
"f2": "v2",
"f3": "v3"
},
"filemetadata": {
"f1": "v1",
"f2": "v2",
"f3": "v3"
},
"last_modified_date": "Thu Jul 16 2020 04:37:41 GMT+0000 (Coordinated Universal Time)",
"gtags": [
"tag01",
"tag02",
"tag03"
],
"ltag": "m19-SeismicDMS-Legal-Tag-Test7649172",
"readonly": false,
"seismicmeta": {
"kind": "m19:seistore:seismic2d:1.0.0",
"legal": {
"legaltags": [
"m19-SeismicDMS-Legal-Tag-Test7649172"
],
"otherRelevantDataCountries": [
"US"
]
},
"data": {
"msg": "Auto Test sample data patched"
}
}
}'
```
And, we get the following error:
```bash
[seismic-store-service] The dataset sd://m19/subprojectodi374308/autotest_path/autotest_new already exists, even so there is no such a dataset in Seismic at the moment
```https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/115path and sdpath not used consistently, error in /user with parameter path2023-09-27T19:34:47ZZachary Keirnpath and sdpath not used consistently, error in /user with parameter pathThere are I think two issues here. One is documentation in that the yaml doc for /user delete option has 'path' instead of 'sdpath' and I believe it should be 'sdpath'. The other is that when I try to delete someone that does not exist,...There are I think two issues here. One is documentation in that the yaml doc for /user delete option has 'path' instead of 'sdpath' and I believe it should be 'sdpath'. The other is that when I try to delete someone that does not exist, I get 400 instead of 404 in response. This is regardless of whether I try 'path' or 'sdpath' for the parameter.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-service/-/issues/104'path' parameter should be optional not required2023-08-29T15:07:30ZZachary Keirn'path' parameter should be optional not requiredThe API docs all state that 'path' is a required field. It looks like it is actually optional and I am told by Mark Yan that the service inserts a "/" if it is not provided. Current collections for testing this all set the 'path' paramet...The API docs all state that 'path' is a required field. It looks like it is actually optional and I am told by Mark Yan that the service inserts a "/" if it is not provided. Current collections for testing this all set the 'path' parameter to an empty string in a pre-request script. But they could be made more clear by just not entering this parameter at all. ALSO, would like to see example of when setting the path is needed and how it should be set under that circumstance. From reading the API doc, it seems to suggest that you would enter the path to the segy file, but if you do that you get following error that seems to insert slashes at start and end of the provided 'path' parameter: The ‘path’ parameter /sd://osdu/testtenant2/ST0202R08_PS_PSDM_RAW_PP_TIME.MIG_RAW.POST_STACK.3D.JS-017534.segy/ is in a wrong format.It should match the regex expression ^[/A-Za-z0-9_.-]*$. In this case, 'path' was set in the params as "sd://osdu/testtenant2/ST0202R08_PS_PSDM_RAW_PP_TIME.MIG_RAW.POST_STACK.3D.JS-017534.segy"Mark YanMark Yanhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-zgy/-/issues/28Please update OpenVDS dependencies in dll-hell.md2023-05-04T14:03:12ZJørgen Lindjorgen.lind@3lc.aiPlease update OpenVDS dependencies in dll-hell.mdVersion 3.2 and newer of OpenVDS does not have any visible dependencies, except sytem libraries such as:
- linux-vdso.so.1
- libpthread.so.0
- libdl.so.2
- libstdc++.so.6
- libm.so.6
- libgcc_s.so.1
- libc.so.6
- ld-linux-x86-64.so.2
T...Version 3.2 and newer of OpenVDS does not have any visible dependencies, except sytem libraries such as:
- linux-vdso.so.1
- libpthread.so.0
- libdl.so.2
- libstdc++.so.6
- libm.so.6
- libgcc_s.so.1
- libc.so.6
- ld-linux-x86-64.so.2
The situation is very similar on Windows. Therefor the mentioning of OpenVDS in the dll-hell section is outdated and should be revised.