[Issue Report]: Manjaro does not have libsodium version 23

[coreybruce]

Operating System

Linux x64

DevilutionX version

1.5.1

Describe

Unable to find libsodium.so.23 library which doesn't exist in my system but I have libsodium.sos, libsodium.so.26 and libsodium.so.26.1.0

I can work around the issue by doing sudo ln -s /usr/lib/libsodium.so.26.1.0 /usr/lib/libsodium.so.23 but it should be finding the library file on it's own.

I am on Manjaro x64

To Reproduce

Run game

Expected Behavior

finds library file in /usr/lib and works

Additional context

No response

[AJenbo]

I would suggest either using appimage, flatpack, or build it from source for your particular system. Or get it form AUR since that should also work for Manjaro from what I read: https://aur.archlinux.org/packages/devilutionx

[coreybruce]

Well hang on this issue isn't complete @AJenbo nor does that fix the issue of running it on Arch/Manjaro as it's looking for libsodium.so.23 when it could easily look for libsodium.so and use that. Closing the issue isn't resolving any issues and just looks unprofessional or unwilling to fix a simple issue.

I can confirm that on Manjaro Arm64 with the packages not yet updated compared to x64 repos that libsodium.so.23 is there and gets updated to libsodium.so.26 so this will need to be addressed and look for libsodium.so instead and use that to avoid the issue again since Manjaro gets much more updated packages compared to Debian and Ubuntu for example

[StephenCWills]

Well hang on this issue isn't complete...

Perhaps you're right. But he switched it to "not planned" so we're not asserting that it's completed.

... nor does that fix the issue of running it on Arch/Manjaro as it's looking for libsodium.so.23 when it could easily look for libsodium.so and use that.

Erm, are you saying you tried AppImage, Flatpack, and AUR and they were all looking for libsodium.so.23?

Plus, it can't be that easy. Like, if you know how to make it easily look for your version of libsodium, then what do you need us for?

Closing the issue isn't resolving any issues and just looks unprofessional or unwilling to fix a simple issue.

"Not planned" means we are indeed not willing. But I think the least you could do is try the suggestions before demanding we do something specific for you.

[AJenbo]

Closing the issue isn't resolving any issues

I didn't close the issue as resolved.

looks unprofessional or unwilling to fix a simple issue.

If you think it's simple to solve then you are free to submit a PR. I don't have an Arch/Manjaro installation to test on and last I tried creating one for it I failed. I'm just doing this as an amature in my spare time.

It's also a priority issue, I would rather focus resources on making it playable by blind users and installable to Android TV users then figuring out how to provide 5 working installation options for Manjaro instead of "only" 4. If you report back that against expectations that none of the options work we could always reopen the issue.

Lastly it was also something we discussed after noticing that libsodium didn't get statically linked (which we generally prefer to avoid issues like this), and will try to avoid during the next release. But not enough of an issue to pull the current release. Hope that helps clarify things.

[coreybruce]

Well hang on this issue isn't complete...

Perhaps you're right. But he switched it to "not planned" so we're not asserting that it's completed.

... nor does that fix the issue of running it on Arch/Manjaro as it's looking for libsodium.so.23 when it could easily look for libsodium.so and use that.

Erm, are you saying you tried AppImage, Flatpack, and AUR and they were all looking for libsodium.so.23?

Plus, it can't be that easy. Like, if you know how to make it easily look for your version of libsodium, then what do you need us for?

Closing the issue isn't resolving any issues and just looks unprofessional or unwilling to fix a simple issue.

"Not planned" means we are indeed not willing. But I think the least you could do is try the suggestions before demanding we do something specific for you.

I know the appimage will work but that wouldn't solve the exact issue but I understand where @AJenbo is coming from but yes the AUR package building it would have the same issue

I would suggest to have it look for the libsodium lib and not a lib of a specific version to solve the issue :)

[coreybruce]

Closing the issue isn't resolving any issues

I didn't close the issue as resolved.

looks unprofessional or unwilling to fix a simple issue.

If you think it's simple to solve then you are free to submit a PR. I don't have an Arch/Manjaro installation to test on and last I tried creating one for it I failed. I'm just doing this as an amature in my spare time.

It's also a priority issue, I would rather focus resources on making it playable by blind users and installable to Android TV users then figuring out how to provide 5 working installation options for Manjaro instead of "only" 4. If you report back that against expectations that none of the options work we could always reopen the issue.

Lastly it was also something we discussed after noticing that libsodium didn't get statically linked (which we generally prefer to avoid issues like this), and will try to avoid during the next release. But not enough of an issue to pull the current release. Hope that helps clarify things.

Ah ok I understand tho I could do that Arch/Manjaro testing for you if you like, I am willing to help out :)

[AJenbo]

I don't know what I would have to change. Is it a debian, gcc, or cmake thing?

but yes the AUR package building it would have the same issue

Why?

[StephenCWills]

I know the appimage will work but that wouldn't solve the exact issue...

Yeah, it would. You said it yourself that you want us to "fix the issue of running it on Arch/Manjaro".

... but yes the AUR package building it would have the same issue

The thing is, judging by the way you worded that, it sounds like you haven't even tried it. I don't know why you expect us to take your word for it here. And if there somehow was an issue with the package referencing the wrong version of libsodium, it seems like you could try to work that out with the package maintainer instead of us.

I would suggest to have it look for the libsodium lib and not a lib of a specific version to solve the issue :)

It's pretty clear to me you don't understand what is actually happening here, and I don't really owe you an explanation. Suffice it to say that the build system determines what version of the library we link against based on what's available on the host at the time, statically linking the library would be a better suggestion, and there are reasons why it works the way it does and why we haven't fixed it yet.

I'm probably not the only one who considers it to be pretty rude when you imply that we're the ones being unreasonable by refusing your strangely specific request on the spurious grounds that it should be easy for us to do the thing that you want. You don't know how easy it is, but you've decided that you do. Therefore, you don't respect our judgment when we contradict your assertion. You are the one being unreasonable.

[coreybruce]

I know the appimage will work but that wouldn't solve the exact issue...

Yeah, it would. You said it yourself that you want us to "fix the issue of running it on Arch/Manjaro".

... but yes the AUR package building it would have the same issue

The thing is, judging by the way you worded that, it sounds like you haven't even tried it. I don't know why you expect us to take your word for it here. And if there somehow was an issue with the package referencing the wrong version of libsodium, it seems like you could try to work that out with the package maintainer instead of us.

I would suggest to have it look for the libsodium lib and not a lib of a specific version to solve the issue :)

It's pretty clear to me you don't understand what is actually happening here, and I don't really owe you an explanation. Suffice it to say that the build system determines what version of the library we link against based on what's available on the host at the time, statically linking the library would be a better suggestion, and there are reasons why it works the way it does and why we haven't fixed it yet.

I'm probably not the only one who considers it to be pretty rude when you imply that we're the ones being unreasonable by refusing your strangely specific request on the spurious grounds that it should be easy for us to do the thing that you want. You don't know how easy it is, but you've decided that you do. Therefore, you don't respect our judgment when we contradict your assertion. You are the one being unreasonable.

Well I did build it from source and I ran into the issue also it is a bit rude to assume I don't know what is going on, like I said I want to help report and resolve the issue and even do tests to help out which doesn't sound unreasonable to want to fix the issue at hand. I don't actually mean it's a simple easy job but with what you said " it to say that the build system determines what version of the library we link against based on what's available on the host at the time" it would be better to look for libsodium.so instead of the specific library version being libsodium.so.23 as that is subject to change as the dependency is subject to change and cause library breakage since the library got updated from libsodium.so.23 to libsodium.so.26

I am only suggesting to try and help out, I don't wish to fight or offend anyone and I am very much willing to do tests on my end since I have a Manjaro install to help because I love this project and what it has done :smiley:

[coreybruce]

I don't know what I would have to change. Is it a debian, gcc, or cmake thing?

but yes the AUR package building it would have the same issue

Why?

The suggestion of change to fix the issue would be done in the cmake file :)

[StephenCWills]

The suggestion of change to fix the issue would be done in the cmake file :)

We don't reference libsodium.so.23, there or anywhere.

https://github.com/diasurgical/devilutionX/blob/45f86478929ba59e1edfe9a7888701079e65f762/CMake/Dependencies.cmake#L190-L192

it is a bit rude to assume I don't know what is going on

I'm not assuming. Demonstrate what you know, and I'll admit that you know what is going on.

[coreybruce]

The suggestion of change to fix the issue would be done in the cmake file :)

We don't reference libsodium.so.23, there or anywhere.

https://github.com/diasurgical/devilutionX/blob/45f86478929ba59e1edfe9a7888701079e65f762/CMake/Dependencies.cmake#L190-L192

it is a bit rude to assume I don't know what is going on

I'm not assuming. Demonstrate what you know, and I'll admit that you know what is going on.

Hmm I see, I wonder why it would specifically choose libsodium.so.23 and not the libsodium.so :thinking:

Do you do the Linux builds on Ubuntu? if so does Ubuntu symlink the libsodium library as libsodium.so like the Arch/Manjaro libsodium package does?

[AJenbo]

So that it doesn't break when the API changes, that's what the version number is for. The issue here may well be that libsodium is unnecessarily bumping there API version when there is no breakage. Or maybe there is breakage and looking for ANY version of libsodium would be unwise.

[coreybruce]

So that it doesn't break when the API changes, that's what the version number is for. The issue here may well be that libsodium is unnecessarily bumping there API version when there is no breakage. Or maybe there is breakage and looking for ANY version of libsodium would be unwise.

Yeah seems like it judging by what's going on

[AJenbo]

This is how things normally work from what I know, I'm surprised you thought we where specifying 23 explicitly. What project are you used to where this is not how it works?

Well I did build it from source and I ran into the issue also

Could you detail what you did, this sounds odd since for this case to happen you would basically have to have the dev files for libsodium 23, but the bin for 26.

like I said I want to help report and resolve the issue

You might have to take it up with libsodium, but I think they will be very resilient to changing this.

[StephenCWills]

Do you do the Linux builds on Ubuntu? if so does Ubuntu symlink the libsodium library as libsodium.so like the Arch/Manjaro libsodium package does?

I'm on Debian, but yes it does.

$ ls -l /usr/lib/x86_64-linux-gnu/libsodium*
-rw-r--r-- 1 root root 600068 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.a
lrwxrwxrwx 1 root root     19 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.so -> libsodium.so.23.3.0
lrwxrwxrwx 1 root root     19 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.so.23 -> libsodium.so.23.3.0
-rw-r--r-- 1 root root 363208 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.so.23.3.0

[coreybruce]

This is how things normally work from what I know, I'm surprised you thought we where specifying 23 explicitly. What project are you used to where this is not how it works?

Well I did build it from source and I ran into the issue also

Could you detail what you did, this sounds odd since for this case to happen you would basically have to have the dev files for libsodium 23, but the bin for 26.

like I said I want to help report and resolve the issue

You might have to take it up with libsodium, but I think they will be very resilient to changing this.

No no I didn't say you guys were specifically looking for libsodium.so.23 but suggesting a better universal way to look for the library to avoid breakage if the version is changed and it does look for that

Well I didn't do anything specifically, I built it from source and later on I got a update for libsodium so I assume when I built it as the instructions explained it found that specially lib and used that instead of the symlinked libsodium.so library and now that I have updated the library no longer exists

[StephenCWills]

You might have to take it up with libsodium, but I think they will be very resilient to changing this.

I believe it's the package maintainers, actually. The actual library version is 1.0.18/1.0.19. Completely unrelated to 23/26.

EDIT: Also, it's entirely possible that there were breaking changes, but we don't use any of the APIs that broke.

[coreybruce]

Do you do the Linux builds on Ubuntu? if so does Ubuntu symlink the libsodium library as libsodium.so like the Arch/Manjaro libsodium package does?

I'm on Debian, but yes it does.

$ ls -l /usr/lib/x86_64-linux-gnu/libsodium*
-rw-r--r-- 1 root root 600068 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.a
lrwxrwxrwx 1 root root     19 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.so -> libsodium.so.23.3.0
lrwxrwxrwx 1 root root     19 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.so.23 -> libsodium.so.23.3.0
-rw-r--r-- 1 root root 363208 Aug 18  2019 /usr/lib/x86_64-linux-gnu/libsodium.so.23.3.0

Right I see well if that is the case I really think it would be better to have Devilutionx look for that symlinked lib file instead of the lib file that exists on the system at the time

After doing sudo ln -s /usr/lib/libsodium.so /usr/lib/libsodium.so.23 the works without any issues

[StephenCWills]

Right I see well if that is the case I really think it would be better to have Devilutionx look for that symlinked lib file instead of the lib file that exists on the system at the time

I really don't agree. It might be okay for this project at this time to go ahead and just use whatever version of the library you and I have, but that may not be the case in general. It's generally better to fail with an error message that indicates the library version is not the same as what the application was built for than to fail on some cryptic API breakage.

[AJenbo]

No no I didn't say you guys were specifically looking for libsodium.so.23 but suggesting a better universal way to look for the library to avoid breakage if the version is changed and it does look for that

How could we do it in a better way if we where not looking for a specific version :thinking:

Well I didn't do anything specifically, I built it from source and later on I got a update for libsodium so I assume when I built it as the instructions explained it found that specially lib and used that instead of the symlinked libsodium.so library and now that I have updated the library no longer exists

Ok, maybe I should have been more clear, but the what I implied in my original post is that you build it on your current system so that it's targeted to that system.

[coreybruce]

Right I see well if that is the case I really think it would be better to have Devilutionx look for that symlinked lib file instead of the lib file that exists on the system at the time

I really don't agree. It might be okay for this project at this time to go ahead and just use whatever version of the library you and I have, but that may not be the case in general. It's generally better to fail with an error message that indicates the library version is not the same as what the application was built for than to fail on some cryptic API breakage.

True and that is a good point tho I feel like this is going to happen a lot as library files change and going to be a ongoing issue compared to the less common/likely problem of a cryptic api error especially when it works fine with the symlink workaround as long as the project maintains it's library dependencies and doesn't rely on a really old version of a lib file that will be outdated

[coreybruce]

No no I didn't say you guys were specifically looking for libsodium.so.23 but suggesting a better universal way to look for the library to avoid breakage if the version is changed and it does look for that

How could we do it in a better way if we where not looking for a specific version 🤔

Well I didn't do anything specifically, I built it from source and later on I got a update for libsodium so I assume when I built it as the instructions explained it found that specially lib and used that instead of the symlinked libsodium.so library and now that I have updated the library no longer exists

Ok, maybe I should have been more clear, but the what I implied in my original post is that you build it on your current system so that it's targeted to that system.

if the dependencies are maintained to use a modern versions of a library it should be fine relying on it as have a minimal version requirement and not for a specific version.

Yes I know/understand that but my point is it shouldn't do that as it causes breakage and should instead universally look for the simlinked lib file and rely on that to avoid breakage from library updates as packages get updated

[StephenCWills]

True and that is a good point tho I feel like this is going to happen a lot as library files change and going to be a ongoing issue compared to the less common/likely problem of a cryptic api error especially when it works fine with the symlink workaround as long as the project maintains it's library dependencies and doesn't rely on a really old version of a lib file that will be outdated

But you're wrong about that too. AJenbo already explained that we had intended to link libsodium statically, and that means we are likely to do so going forward for future release versions. You wouldn't be having this problem if the dependency was statically linked.

[AJenbo]

Right I see well if that is the case I really think it would be better to have Devilutionx look for that symlinked lib file instead of the lib file that exists on the system at the time

I really need some details about how this would be the right way to go since it's against both how Ubuntu and Manjaro have setup things up. To me what you are saying just sounds like "Works on my machine™"

True and that is a good point tho I feel like this is going to happen a lot as library files change and going to be a ongoing issue compared to the less common/likely problem of a cryptic api error especially when it works fine with the symlink workaround as long as the project maintains it's library dependencies and doesn't rely on a really old version of a lib file that will be outdated

Congratulations on selecting a distro that does rolling releases as you main driver. Being on a system like that basically expects you to rebuild your software continuously to match the installed libraries. From what I understand this exactly how AUR packages work on Manjaro/Arch.

[coreybruce]

True and that is a good point tho I feel like this is going to happen a lot as library files change and going to be a ongoing issue compared to the less common/likely problem of a cryptic api error especially when it works fine with the symlink workaround as long as the project maintains it's library dependencies and doesn't rely on a really old version of a lib file that will be outdated

But you're wrong about that too. AJenbo already explained that we had intended to link libsodium statically, and that means we are likely to do so going forward for future release versions. You wouldn't be having this problem if the dependency was statically linked.

"When you statically link a file into an executable, the contents of that file are included at link time. In other words, the contents of the file are physically inserted into the executable that you will run." so why don't you link libsodium.so which is the sodium package automatically creates when the package is installed, this isn't something that Ubuntu or other distros don't do since you demonstrated yourself as Debian does the exact same thing.

[AJenbo]

if the dependencies are maintained to use a modern versions of a library it should be fine relying on it as have a minimal version requirement and not for a specific version.

Well that is why it's locked in at build time, libsodium.26 was not a thing when 1.5.1 came out, there was no way for any one to know if DevilutionX would be compatible with it since it had only been tested against libsodium.23, no other information was available at build time. We can't future proof things since we don't know what the future looks like, no guarantee is provided by libsodium that they will not change there API in ways that will affect us by the next release.

I feel you are still under the assumption that we control how this works, but this is something that happens in the linker based on the build environment. You are practically suggesting an update to the ELF file format and how Linux distros manage their libraries.

[coreybruce]

Right I see well if that is the case I really think it would be better to have Devilutionx look for that symlinked lib file instead of the lib file that exists on the system at the time

I really need some details about how this would be the right way to go since it's against both how Ubuntu and Manjaro have setup things up. To me what you are saying just sounds like "Works on my machine™"

True and that is a good point tho I feel like this is going to happen a lot as library files change and going to be a ongoing issue compared to the less common/likely problem of a cryptic api error especially when it works fine with the symlink workaround as long as the project maintains it's library dependencies and doesn't rely on a really old version of a lib file that will be outdated

Congratulations on selecting a distor that does rolling releases as you main driver. Being on a system like that basically expects you to rebuild your software continuously to match the installed liberiers. From what I understand this exactly how AUR packages work on Manjaro/Arch.

"I really need some details about how this would be the right way to go since it's against both how Ubuntu and Manjaro have setup things up. To me what you are saying just sounds like "Works on my machine™""

How exactly is that against what Manjaro and Ubuntu do? the package itself maintained by the developers creates that symlink of the latest lib it has so why not take advantage of it and avoid this breakage? Also I never said "it works on my machine" you made that assumption and I only gave suggestions on how to give it and now you guys are being rude for me pointing out the issue and attacking me when I give a suggestion of a solution with the mention of a workaround, I am trying to be nice here and you guys are just being rude lol

"Congratulations on selecting a distor that does rolling releases as you main driver. Being on a system like that basically expects you to rebuild your software continuously to match the installed liberiers. From what I understand this exactly how AUR packages work on Manjaro/Arch."

The same thing will happen with Debian and Ubuntu when they update the libsodium package, it also doesn't have to be the case of rebuilding if you use the symlink libsodium provides instead..

[StephenCWills]

so why don't you link libsodium.so which is the sodium package automatically creates when the package is installed, this isn't something that Ubuntu or other distros don't do since you demonstrated yourself as Debian does the exact same thing.

This is all the stuff that I was saying you do not understand, and you have now clearly demonstrated that you do not understand any of it.

We don't link libsodium.so because we don't have control over it. CMake doesn't link libsodium.so because the developers behind that tool recognize that it's better to have breakage at load time than cryptic API breakage that is difficult to trace to a cause. And we would rather use static linkage for our release builds because they aren't tied to a specific distro or package management system that has tighter control over the versions of dynamically linked libraries that would be available on the system where the package is installed.

[coreybruce]

if the dependencies are maintained to use a modern versions of a library it should be fine relying on it as have a minimal version requirement and not for a specific version.

Well that is why it's locked in at build time, libsodium.26 was not a thing when 1.5.1 came out, there was no way for any one to know if DevilutionX would be compatible with it since it had only been tested against libsodium.23, no other information was available at build time. We can't future proof things since we don't know what the future looks like, no guaranty is provided by libsodium that they will not change there API in ways that will affect us by the next release.

I feel you are still under the assumption that we control how this work, but this is something that happens in the linker based on the build environment. You are practically suggesting an update to the ELF file format and how Linux distros manage there liberies.

And that is understandable, I want to let you know that it does work with libsodium.so.26 with no issues, I understand that might not always be the case with newer updates hypothetically but I can confirm that it does work

No I know you don't control libsodium, I never thought that I know that your only relying on someone else's library of Devilutionx

[coreybruce]

so why don't you link libsodium.so which is the sodium package automatically creates when the package is installed, this isn't something that Ubuntu or other distros don't do since you demonstrated yourself as Debian does the exact same thing.

This is all the stuff that I was saying you do not understand, and you have now clearly demonstrated that you do not understand any of it.

We don't link libsodium.so because we don't have control over it. CMake doesn't link libsodium.so because the developers behind that tool recognize that it's better to have breakage at load time than cryptic API breakage that is difficult to trace to a cause. And we would rather use static linkage for our release builds because they aren't tied to a specific distro or package management system that has tighter control over the versions of dynamically linked libraries that would be available on the system where the package is installed.

I do understand and get that, you want versional control with the project I am just wanting to help give some solutions and ideas to make it more universal without issues or minor workarounds that is all. :)

[AJenbo]

the package itself maintained by the developers

Packages are usually not maintained by the developers. I feel you are under a lot of misconception and thinking we are being rude for not agreeing with your understanding of how things work.

Again, if you can provide either a PR that changes this, an example, or some dokumentation that lays out how this is all supposed to work then we can look at changing it but "just look for another file" is not something that we can just do since from our perspective we aren't doing do.

How exactly is that against what Manjaro and Ubuntu do?

Because of how the buildchain works and how packages are versioned in the distros.

also I never said "it works on my machine" you made that assumption

Then what where you saying here: "After doing sudo ln -s /usr/lib/libsodium.so /usr/lib/libsodium.so.23 the works without any issues"

[StephenCWills]

I do understand and get that, you want versional control with the project I am just wanting to help give some solutions and ideas to make it more universal without issues or minor workarounds that is all. :)

Then you should have suggested statically linking the library. And I would have said, "Sure, we'll do that for the next release, but not this one." And the issue would still be closed, and you would have demonstrated that you understood the concepts that I just had to explain to you.

[AJenbo]

The same thing will happen with Debian and Ubuntu when they update the libsodium package

No, their user packages are prebuilt against the specific version. And in the case of self-built applications they are guaranteed to work for the duration of the supported window. For a rolling release that can happen at any given point.

also doesn't have to be the case of rebuilding if you use the symlink libsodium provides instead..

Tell that to them then.

[AJenbo]

And that is understandable, I want to let you know that it does work with libsodium.so.26 with no issues, I understand that might not always be the case with newer updates hypothetically but I can confirm that it does work

How do you know there is no issues with it, what have you tested? Do you actually know what would be required to test this?

[AJenbo]

and get that, you want versional control with the project

That's not the case.

I am just wanting to help give some solutions and ideas to make it more universal without issues or minor workarounds that is all. :)

I get that, but please understand that it's not how things work. Also we already have a planned solution as stated several times.

[coreybruce]

Packages are usually not maintained by the developers. I feel you are under a lot of misconception and thinking we are being rude for not agreeing with your understanding of how things work.

Again I never assumed that also I am calling the way I am being down talked and the overall rude way I am being spoken to for simply making suggestions and reporting a issue..

Because of how the buildchain works and how packages are versioned in the distros.

Could you explain in more detail so I don't misunderstand your standpoint?

Then what where you saying here: "After doing sudo ln -s /usr/lib/libsodium.so /usr/lib/libsodium.so.23 the works without any issues"

No I simply provided a workout that does work and wanted to share that to you guys

[AJenbo]

Hmm I think I'm seeing the source of some of the confusion. @coreybruce what do you think static linkage to be?

[coreybruce]

And that is understandable, I want to let you know that it does work with libsodium.so.26 with no issues, I understand that might not always be the case with newer updates hypothetically but I can confirm that it does work

How do you know there is no issues with it, what have you tested? Do you actually know what would be required to test this?

Well based on testing it I know it works but again I wanted to report it to you and happy to work with you guys to do more further testing for a next release or to help with other solutions

[coreybruce]

Hmm I think I'm seeing the source of some of the confusion. @coreybruce what do you think static linkage to be?

I gave a definition of it in the previous messages

[AJenbo]

And that is understandable, I want to let you know that it does work with libsodium.so.26 with no issues, I understand that might not always be the case with newer updates hypothetically but I can confirm that it does work

Ok, well if you can confirm that it will also work correctly with libsodium.so.82 then I think we will be good to go...

I gave a definition of it in the previous messages

I just searched through all your messages in this issue and at no point did you even mention the word "static" outside of quoting StephenCWills. I'm also trying to be nice but your being a bit obtuse here which is probably why you are picking up an annoyed vibe from us at this point. I don't intend to be rude and I'm actually doing my best to try to explain to you how thing work so you might better understand why things are as they are.

If you don't mind could you please state what you think static linkage (copy paste your previous definition if I actually missed it), I think we would get a lot further with aligning our conversation if we can settle a few basic terms.

[StephenCWills]

I gave a definition of it in the previous messages

Perhaps this is what AJenbo is getting at: libsodium.so is a dynamic library that can only be linked dynamically. It would not be used at all, during build time or during runtime, if the library is statically linked. If we statically link the library, we are not going to use libsodium.so, libsodium.so.23, or libsodium.so.26.. at all.

[AJenbo]

Well based on testing it I know it works but again I wanted to report it to you and happy to work with you guys to do more further testing for a next release or to help with other solutions

You are most welcome to do so. Though it would be better if you can test the develop versions instead so that we can catch issues prior to release. Managin the project takes a lot of time so releases do not happen as often as I would like which unfortunately means that anything missed prior to a release probably stay an issue for a while.

[AJenbo]

If Debian/Ubuntu/Arch/Manjaro etc. felt that it would be generally save to use libsodium.so.26 for any application that was linked against libsodium.so.23 then they could have A: Made two symlinks B: Not changed the version.

Well based on testing it I know it works

At least say what was tested. You might not have invoked any the functionality that relies on libsodium. For all we know the intro video works, but trying to join a ZT game causes a kernel panic :shrug:

[coreybruce]

libsodium.so.82

libsodium.so.82

[coreybruce]

At least say what was tested. You might not have invoked any the functionality that relies on libsodium. For all we know the intro video works, but trying to join a ZT game causes a kernel panic 🤷

How would we test that?

[AJenbo]

Packages are usually not maintained by the developers. I feel you are under a lot of misconception and thinking we are being rude for not agreeing with your understanding of how things work.

Again I never assumed that

You litterally said "the package itself maintained by the developers", what did you mean if not that the package was being maintained by the developer?

libsodium.so.82

What I'm saying is that systems do not link against generic versions like that since it would risk completely unknown behavior later in the future. Evem of some abitery midpoint was tested.

Then what where you saying here: "After doing sudo ln -s /usr/lib/libsodium.so /usr/lib/libsodium.so.23 the works without any issues"

No I simply provided a workout that does work and wanted to share that to you guys

But are you not saying that it works because you did some testing on your machine, and that is also the only assurance that you give for it? That is what I mean when I say "works on my machine".

"When you statically link a file into an executable, the contents of that file are included at link time. In other words, the contents of the file are physically inserted into the executable that you will run."

I guess this is what you meant by you meant when you said you gave a definition. But I was hoping that you would explain it in your own words so we could better understand what info you might be missing.

We are not trying to be rude, just simply trying to figure out the source of the misunderstanding and better explain how it actually works. From our perspective you just reject this and ask us to apply a workaround instead, which isn't really productive.

so why don't you link libsodium.so which is the sodium package automatically creates when the package is installed, this isn't something that Ubuntu or other distros don't do since you demonstrated yourself as Debian does the exact same thing.

This statement doesn't make much sens to me.

• The linker determins what version is linked, not us.
• .so files are not used when static linking is being used. Instead the lib is included in the executable at link time.
• We never said that linking is distro specific.

How would we test that?

I think you are coming at this from a perspective of a user with no access to the source trying to find a workaround for an issue, but you are trying to pitch it to the application developers who have a planed solution.

Please, see the last bit of this message from yestaday where I explain to you that this issue is already known and should be resolved in the next release: https://github.com/diasurgical/devilutionX/issues/6793#issuecomment-1800964488

If you want to learn about how thing work please join the chat, the issue tracker isn't the place for that.

[coreybruce]

You litterally said "the package itself maintained by the developers", what did you mean if not that the package was being maintained by the developer?

I assume you are refurring to libsodium not being developed/maintained by you guys?

What I'm saying is that systems do not link against generic versions like that since it would risk completely unknown behavior later in the future. Evem of some abitery midpoint was tested.

I understand that but compared to how many times it will potentially break compared to that happening and could be tested against newer versions to ensure the best universal compatibility.

But are you not saying that it works because you did some testing on your machine, and that is also the only assurance that you give for it? That is what I mean when I say "works on my machine".

Nah I was simply documenting a workaround so you guys knew about it so there could be more information about the issue and potentially work on a solution in the future.

I think you are coming at this from a perspective of a user with no access to the source trying to find a workaround for an issue, but you are trying to pitch it to the application developers who have a planed solution.

No I have the source code and compiled it myself and a developer/package manager, I am also have a devilutionx-bin package for convenience for x64, i386 and Arm64 compiled but I noticed a issue and wanted to report it while also reporting a workaround, I never said the workaround was the overall solution and more of a work around I wanted to document with you guys to give you the most information I can and help out but for the time being I have applied that workaround into my package to ensure compatibility and avoid issues until it is fixed.

Please, see the last bit of this message from yestaday where I explain to you that this issue is already known and should be resolved in the next release: https://github.com/diasurgical/devilutionX/issues/6793#issuecomment-1800964488

Awesome thanks for letting me know :+1:

[AJenbo]

I assume you are refurring to libsodium not being developed/maintained by you guys?

No, I'm saying that the people maintaining a package in a distro is most often not the actual developers of that software.

I understand that but compared to how many times it will potentially break compared to that happening and could be tested against newer versions to ensure the best universal compatibility.

If you belive this to be an issue you will find that this isn't a DevilutionX specific issue and likely an issue with almost every piece of software you run and use. Try inspecting there dependencies with ldd.

Nah I was simply documenting a workaround so you guys knew about it so there could be more information

From what I understood you could probably have pointed it to any dummy file and it would have "worked" since you never invoked it. It just let the application boot as the needed files appeared to be there. I wish you should have better trusted us when we said this wasn't viable.

for the time being I have applied that workaround into my package to ensure compatibility and avoid issues until it is fixed.

Please do not do this, instead simply rebuild for your current system so that it will link with the version you have. Or statically link it if you want to help others avoid this issue, but please don't create a version of the app with unknown side effects and distribute it.

No I have the source code

I'm not saying you literally do not have access to it, of cause you do, but the perspective of how you are trying to solve things.

[coreybruce]

No, I'm saying that the people maintaining a package in a distro is most often not the actual developers of that software.

I know that

If you belive this to be an issue you will find that this isn't a DevilutionX specific issue and likely an issue with almost every piece of software you run and use. Try inspecting there dependencies with ldd.

In all of my time compiling software or repackaging them I have never ran into this issue except for here

From what I understood you could probably have pointed it to any dummy file and it would have "worked" since you never invoked it. It just let the application boot as the needed files appeared to be there. I wish you should have better trusted us when we said this wasn't viable.

I tested that, it doesn't work

./diablo: error while loading shared libraries: /usr/lib/libsodium.so.23: file too short

Please do not do this, instead simply rebuild for your current system so that it will link with the version you have. Or statically link it if you want to help others avoid this issue, but please don't create a version of the app with unknown side effects and distribute it.

I did it because Arch/Manjaro x64 have the library updated and Manjaro Arm64 hasn't has this update yet and to fix the issue, I don't want to have to recompile on x64, Arm64 and i386 hardware everytime this issue randomly occurs and be told by users that there is a missing dependency. I will remove the fix when the next release comes out also there hasn't been any proof of any unknown side effects.

I wouldn't say I have tried to solve anything yet, I only mentioned a workaround and suggestions of changes in the makefile itself to resolve a issue for when it gets compiled and reporting a issue so we can work together to create a better solution.