CSFML D: Missing symbol errors - graphics

I am using the official (dynamic) D bindings to CSFML (https://github.com/BindBC/bindbc-sfml).
As a prerequisite, I installed CSFML 2.5 using the following command (my operating system is Linux):
sudo apt-get install libcsfml-dev
I then imported the dynamic libraries into my project typed in the following code to get started...
Main code:
import std.stdio;
import bindbc.sfml;
import bindbc.loader;
import std.string;
import std.conv;
import loader = bindbc.loader.sharedlib;
void loadDyn() {
if (!loadSFML()) {
string[] messages;
foreach (const(ErrorInfo) err; loader.errors) {
string errorStr = to!string(err.error);
string messageStr = to!string(err.message);
messages ~= format("Error: %s, Message: %s", errorStr, messageStr);
}
throw new Exception(format("Fatal error(s) encountered whilst calling `loadSFML()` function: %s %s %s", messages, loadedSFMLSystemVersion(), loadedSFMLGraphicsVersion()));
}
}
void main() {
loadDyn();
sfContextSettings* settings;
sfRenderWindow* window = sfRenderWindow_create(sfVideoMode(640, 480), "Hi", sfWindowStyle.sfDefaultStyle, settings);
while (window.sfRenderWindow_isOpen()) {
sfEvent event;
while (window.sfRenderWindow_pollEvent(&event)) {
if (event.type == sfEventType.sfEvtClosed) {
window.sfRenderWindow_close();
}
}
window.sfRenderWindow_clear(sfBlack);
window.sfRenderWindow_display();
}
}
dub.json
{
"authors": [
"Tom"
],
"dependencies": {
"bindbc-sfml": "~>1.0.1",
"bindbc-loader": "~>1.0.0"
},
"versions": [
"SFML_Audio",
"SFML_Graphics",
"SFML_250"
],
"description": "A minimal D application.",
"license": "proprietary",
"name": "sfml"
}
Running the program, I get the following errors:
object.Exception#source/app.d(20):
Fatal error(s) encountered whilst calling `loadSFML()` function: [
"Error: Missing Symbol, Message: sfRenderTexture_createWithSettings",
"Error: Missing Symbol, Message: sfRenderTexture_getMaximumAntialiasingLevel",
"Error: Missing Symbol, Message: sfText_getLineSpacing",
"Error: Missing Symbol, Message: sfText_getLineSpacing"
] sfml250 sfml240
----------------
source/app.d:20 void app.loadDyn() [0x55d6ef8b19c2]
source/app.d:25 _Dmain [0x55d6ef8b19e4]
Program exited with code 1
I asked for help about this issue online, and the owner of the library told me to check my SFML system and SFML graphics versions by calling the loadedSFMLSystemVersion() and loadedSFMLGraphicsVersion() functions.
The loadedSFMLSystemVersion() function returned 2.5.0 whilst the loadedSFMLGraphicsVersion() returned 2.4.0. There is a version conflict.
The owner of the bindings had this to say about the problem:
Usually, a failure to load the configured version is because a lower version of the C library is installed (as in, you've asked for 2.5, but only have 2.4 installed). But that's not always the case. It could also be because there's a bug in the binding, or because the shared library was compiled without support for specific functions, or maybe the shared library has somehow become corrupt.
So, back to your specific case. Though it's possible that a CSFML apt package would bundle one version of the CSFML graphics library and another version of everything else, it seems rather unlikely. CSFML 2.5 means 2.5 of everything. And looking at the official apt repository lists, they show the package has 2.5 of everything. You could verify this by looking for the shared libraries on your system, but there's no need. I'm sure you have 2.5 installed.
Furthermore:
My first thought at this stage would be to look for a bug in the binding. Perhaps the function names are misspelled. But that's not the case. Everything is spelled correctly.
So my next thought would be to check the shared library. Maybe the build was misconfigured so that the missing functions weren't properly exported.
The owner of the library is suggesting that the version conflict is due to an internal issue/bug, which I am unable to properly find as it's out of my scope.
For some reason, downgrading to version 2.4 fixes this issue, but I would like to use version 2.5 which I am unable to due to these errors.

Looking at the code that sets the system version
It looks like the value returned by loadedSFMLSystemVersion will always be whatever you have defined for the version (it just sets the value to the enum defined in config.d), regardless of the support of the library.
So I don't think this mismatch is indicative of the error. What seems to be happening is that the code that loads the graphics binding isn't finding one or more of the functions that it requires to declare that 2.5 is supported.
See the list of functions here, at least one of these isn't loading.
Looking at your first error message, it's the first function in the list. Indeed, I'd say it really does appear that the library is not the 2.5 version, but the 2.4 version.
I am not familiar with this library, but the first thing I would check is whether you have the right .so file. To do this try:
dpkg -L libcsfml-dev
This might tell you what library version you have installed.
If you do think this is the right version, try using nm on the .so file, and see if you can find that symbol defined there. If not, then the built library just doesn't include that function. Perhaps that's because the function name is incorrect in the bindbc binding, and perhaps it's as the author says -- the library wasn't built with that function.

Related

How to get a working x64 THREADSAFE Ghostscript DLL

Main context
We're actually trying to get a multi-threading version of Ghostscript x64 DLL, to make use of it through Ghostscript .NET. This component is supposed to "allow runing multiple Ghostscript instances simultaneously within a single process", but, as we have checked in our project, works fine until concurrent requests are made to the application. Same behavior can be replicated lauching same method using Tasks. The error description that raises in both cases, just when a call to the process is made until the last is being executed, is:
An error occured when call to 'gsapi_new_instance' is made: -100
Even it does no seem to be related with .NET directly, I will post a sample of our C# method code, just for contextualize.
// Define switches...
string[] switchesArray = switches.ToArray();
using (GhostscriptProcessor procesador = new GhostscriptProcessor())
{
try
{
procesador.StartProcessing(switchesArray, null);
byte[] destinationFile = System.IO.File.ReadAllBytes(destinationPath);
return destinationFile;
}
catch (Exception ex)
{
throw ex;
}
finally
{
System.IO.File.Delete(sourceFile);
}
}
THREADSAFE solution
Starting our investigation, we found this KenS's answer on this post, indicating that Ghostscript DLL must be generated with GS_THREADSAFE compiler definition.
To clarify, as we make use of Ghostscript 9.52 x64 to generate our PDFs, we need this x64 DLL compiled for Release configuration. After trying to compile Ghostscript sources on Windows 10 x64 machine, using Visual Studio Community 2017 and Visual Studio Community 2019, we finally managed to build and generate all items (only with VS Community 2019) without GS_THREADSAFE parameter, just to confirm that compilation is fine, and we check that the DLLs and executables are working. For this process we took in mind all we found in Ghostscript official documentation.
As we have no other guide to include this GS_THREADSAFE parameter, we followed the instructions given in this solution, including XCFLAGS="-DGS_THREADSAFE=1" on nmake build commands, usign this sentence for Rebuild all option:
cd .. && nmake -f psi\msvc32.mak WIN64= SBR=1 DEVSTUDIO= XCFLAGS=-DGS_THREADSAFE=1 && nmake -f psi\msvc32.mak WIN64= DEVSTUDIO= XCFLAGS=-DGS_THREADSAFE=1 bsc
This approach, rises an error during build:
Error LNK2019 unresolved external symbol errprintf_nomem referenced in
function gs_log_error File \mkromfs.obj 1
As it seems, the file mkromfs.c has a method called errprintf_nomem, which can't be found when GS_THREADSAFE is set.
Questions
1 - Is there any public release of Ghostscript that include x64 DLLs compiled to be THREADSAFE?
And, if not (that's what I'm guessing...)
2 - Is it possible to get this DLL to be THREADSAFE without changing the source code?
3- Could anyone provide, please, a step by step guide or walkthrough to build a x64 Ghostscript DLL using GS_THREADSAFE using Visual Studio (or even any other possible alternative) over Windows 10 x64?
4 - A few posts talk about people achive to manage multithreading using Ghostscript .NET. I assume this examples are all using a GS_THREADSAFE DLL... Is any other workaround we have passed?
Thank a lot in advance.
To summarize all this questions, and as a guide for future developers having this same trouble, these are the answers we've found until now:
AS #KenS mentions in his reply: "No, the Ghostscript developers don't actually build thread-safe versions of the binaries."
At this very moment, clearly not, as it has been reported on this opened bug.
As it seems to be a matter of commercial licensing support, we avoid comment on this point anymore.
Thanks again to #HABJAN. I absolutely take back what I've stated on my question, as it is possible to have Ghostscript .NET working on multi-threading scenarios. Below comes the solution we applied, in case it could be useful for someone.
Based on HABJAN example, what we have done to achieve this was to create a custom class to capture Ghostscript logging:
protected class ConsoleStdIO : Ghostscript.NET.GhostscriptStdIO
{
public ConsoleStdIO(bool handleStdIn, bool handleStdOut, bool handleStdErr) : base(handleStdIn, handleStdOut, handleStdErr)
{
}
public override void StdIn(out string input, int count)
{
char[] userInput = new char[count];
Console.In.ReadBlock(userInput, 0, count);
input = new string(userInput);
}
public override void StdOut(string output)
{
//log
}
public override void StdError(string error)
{
//log
}
}
For our previous method, we simple include a call to this class and this avoids errors when multiple tasks are executed at the same time:
// Define switches...
string[] switchesArray = switches.ToArray();
using (GhostscriptProcessor procesador = new GhostscriptProcessor())
{
try
{
procesador.StartProcessing(switchesArray, new ConsoleStdIO(true, true, true));
byte[] destinationFile = System.IO.File.ReadAllBytes(destinationPath);
return destinationFile;
}
catch (Exception ex)
{
throw ex;
}
finally
{
System.IO.File.Delete(sourceFile);
}
}
Well, it seems to me that you are asking here for technical support.
You clearly want to use Ghostscript in a commercial undertaking, indeed one might reasonably say you want an enterprise version of Ghostscript. Presumably you don't want to alter the source in order to permit you to use an open source license, because you don't want to pay for a commercial license.
With that in mind the answers to your questions are:
No, the Ghostscript developers don't actually build thread-safe versions of the binaries.
Currently, no. That's probably an oversight.
That would be a technical support question, there's no guarantee of technical support to free users, it's the one of the few areas of leverage for dual license vendors to persuade people to take up a commercial license. So I hope you will understand that I'm not going to provide that.
as far as I can see, no.

Azure Function: "Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information"

I have an F# Azure Function that is failing, in a bizarre way, and don't know how to approach fixing the issue. I created a minimum repro of the actual case below. The test function is manually triggered and uses FSharp.Compiler.Service as a dependency, as specified in the project.json below:
{
"frameworks": {
"net46":{
"dependencies": {
"FSharp.Compiler.Service": "11.0.6"
}
}
}
}
The run.fsx file looks like this:
open System
open Microsoft.FSharp.Compiler
open Microsoft.FSharp.Compiler.Ast
open Microsoft.FSharp.Compiler.Interactive.Shell
let Run(input: string, log: TraceWriter) =
// code here that uses FsiEvaluationSession
// and runs just fine
log.Info "I RAN"
So far, so good. The part that baffles me is that if I add the following function above Run,
// same dependencies as before
open Microsoft.FSharp.Compiler.Interactive.Shell
let foo (longIdent:LongIdent) =
// version 1
// "FOO"
// version 2
// longIdent.ToString ()
// version 3
longIdent |> List.map string
let Run(input: string, log: TraceWriter) =
// same as before
Uncommenting section 1 alone works fine, uncommenting section 2 alone works fine, uncommenting section 3 causes hell to break loose. The function compiles, but running it causes the following exception:
Exception while executing function: Functions.fsc-1. mscorlib: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
... which is puzzling to me, because
foo isn't even called anywhere
the signature and the 2nd version both use LongIdent, so this type doesn't seem to be the source of the problem.
Any suggestion on how to approach the problem, and what the problem itself might be, would be very appreciated - I don't even know where to start, and the same code runs perfectly fine in a local script.
I believe the reason for this is that Azure Functions SDK depend on FSharp.Compiler.Service (FCS) version 9.0.1. This means that when you try to load a different version of FCS, you will get the already loaded version 9.0.1.
This works as long as the public API of the FCS version you are using matches the public API of version 9.0.1, but when there are differences, it will crash, because your code assumes that the public API looks different. I suppose this might be triggering the issue here, although I'm not 100% sure how (possibly, LongIdent is now a different thing than it was in version 9.0.1?)
The very same issue used to happen with FAKE, which also bundles FCS and prevented loading of different versions. One of the options is to rename the assembly to avoid the clash.
I also got the same error, I solved it by doing the following workaround, please refer if it works for you also.
Right-click on the Project and select properties.
Goto Debug tab and create a profile with the reference to the below
screenshot.
Note: Replace UserName with your username.

Groovy version downgrade 2.2.1

We have been building our application using groovy 2.3.6. Now because of some platform level issues we are advised to downgrade our groovy version to 2.2.1. I am facing no. of issues regarding this downgrade.
groovy is not able to infer the type of it variable in ver 2.2.1 so if i have code something like this
names.any { sliceName.endsWith(it) }
it gives me exception
[Static type checking] - Cannot find matching method java.lang.String#endsWith(java.lang.Object)
Secondly all the default method that i had used in collections no longer seem to exist
positions.any { it.primary }
groovy is unable to find the any method on list.
One way would be turn off static type checking, which will expose the code to a lot more runtime errors.
Is there any way to resolve these errors, without turning off static type checking. Also are these features only added in groovy 2.3.6 like default groovy methods and type inference for it variable
If you go back to an old version, old bugs will bite you.
Try giving the static compiler more of a hint
names.any { String it -> sliceName.endsWith(it) }

Referring to core modules from NativeScript UI plugin

I'm working on a UI component in VIM with TypeScript plugin that highlights the errors on the spot, so it's not something I get during the actual plugin installation into the app at this point (although I haven't tried yet).
declare module "card-view" {
import view = require("ui/core/view");
export class CardView extends view.View {
}
}
And I get this:
Cannot find module 'ui/core/view'.
I realize that ui/core/view is unavailable at this point, since it's a standalone plugin, but it will be available at runtime. Is there anything to be done to resolve the error? I must be missing some step that wasn't mentioned in the guide -- http://docs.nativescript.org/plugins/ui-plugin.
UPDATE 1:
When I got to card-view-common.js implementation I hit another issue. TypeScript expects android and ios properties to be implemented, but since the class extends View (from ui/core/view) they are supposed to be implemented there. In other words, I believe I still need to somehow point to the existing core module, not sure how though.
Found it. I added a devDependency to package.json with tns-core-modules like below, ran npm install and then it began recognizing the module. Makes sense if you think about how it is supposed to compile the module during the development phase without installing in the real app, but may be worth mentioning in the guide anyway.
"devDependencies": {
"tns-core-modules": "^1.5.1"
}
'ui/core/view' (and the modules, distributed through the tns-core-modules package are declared as ambient external modules.
It could be that the vim plugin you use does not recognize ambient modules correctly.

Problems using MemoryMappedFile class on Mono

I'm trying to port a new versio of the Isis2 library from .NET on Windows to Mono/Linux. This new code uses MemoryMappedFile objects, and I suddenly am running into issues with the Mono.Posix.Helper library. I believe that my issues would vanish if I could successfully compile and run the following test program:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO.MemoryMappedFiles;
namespace foobar
{
class Program
{
static int CAPACITY = 100000;
static void Main(string[] args)
{
MemoryMappedFile mmf = MemoryMappedFile.CreateNew("test", CAPACITY);
MemoryMappedViewAccessor mva = mmf.CreateViewAccessor();
for (int n = 0; n < CAPACITY; n++)
{
byte b = (byte)(n & 0xFF);
mva.Write<byte>(n, ref b);
}
}
}
}
... at present, when I try to compile this on Mono I get a bewildering set of linker errors: it seems unable to find libMonoPosixHelper.so, although my LD_LIBRARY_PATH includes the directory containing that file, and then if I manage to get past that stage, I get "System.NotImplementedException: The requested feature is not implemented." at runtime. Yet I've looked at the Mono implementation of the CreateNew method; it seems fully implemented, and the same is true for the CreateViewAccessor method. Thus I have a sense that something is going badly wrong when linking to the Mono libraries.
Does anyone have experience with MemoryMappedFile objects under Mono? I see quite a few questions about this kind of issue here and on other sites, but all seem to be old threads...
OK, I figured at least part of this out by inspection of the Mono code implementing this API. In fact they implemented CreateNew in a way that departs pretty drastically from the .NET API, causing these methods to behave very differently from what you would expect.
For CreateNew, they actually require that the file name you specify be the name of an existing Linux file of size at least as large as the capacity you specify, and also do some other checks for access permissions (of course), exclusive access (which is at odds with sharing...) and to make sure the capacity you requested is > 0. So if you had the file previously open, or someone else does, this will fail -- in contrast to .NET, where you explicitly use memory-mapped files for sharing.
In contrast, CreateOrOpen appears to be "more or less" correctly implemented; switching to this version seems to solve the problem. To get the effect of CreateNew, do a Delete first, wrapping it in a try/catch to catch IOException if the file doesn't exist. Then use File.WriteAllBytes to create a file with your desired content. Then call CreateOrOpen. Now this sounds dumb, but it works. Obviously you can't guarantee atomicity this way (three operations rather than one), but at least you get the desired functionality.
I can live with these restrictions as it works out, but they may surprise others, and are totally different from the .NET API definition for MemoryMappedFile.
As for my linking issues, as far as I can tell there is a situation in which Mono doesn't use the LD_LIBRARY_PATH you specify correctly and hence can't find the .so file or .dll file you used. I'll post more on this if I can precisely pin down the circumstances -- on this one, I've worked around the issue by statically linking to the library.

Resources