Can't compile GStreamer-Sharp on OS X - c#

I'm trying to use Gst# (which is the C# bindings for GStreamer) on Mac, but autotools keeps failing with these last few lines:
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /opt/local/bin/pkg-config
Reason: Incompatible library version: pkg-config requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
./configure: line 11558: 15968 Trace/BPT trap: 5 $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version
no
checking for MONO_DEPENDENCY... no
checking for csc.exe... no
configure: error: You need to install either mono or .Net
Saying that Mono isn't installed is nonsense; how can I fix this and get it to succeed? If it helps, I installed Mono through the Mac installer, not Macports, though Macports is installed.

Your mono installation is not in $PKG_CONFIG_PATH, and that's why pkg-config cannot find the .pc files for mono.
You need to add the directory to your $PKG_CONFIG_PATH environment variable. The directory should be at /Library/Frameworks/Mono.framework/Versions/VERSIONNUMBER/lib/pkgconfig/

The error is explained quite clearly:
Reason: Incompatible library version: pkg-config requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
In order to update to a newer version I would suggest trying this in Terminal:
sudo port -n upgrade --force libiconv
More information here.

Related

Dotnet: Works in VSCode's OWN TERMINAL, but OMNISHARP: 'dotnet.exe' is not recognized

How is this possible?
I installed .net sdk 6.0.405: dotnet-sdk-6.0.405-win-x64.exe
I can in windows terminal and power shell run: dotnet --version: 6.0.405 ✅
I CAN ALSO IN VSCODE IN ITS BUILTIN TERMINAL, run: dotnet --version: 6.0.405 ✅✅
But in the OUTPUT tab, choosing OmniSharp Log from the dropdown, it says:
[ERROR] A .NET 6 SDK for x86_64 was not found. Please install the latest x86_64 SDK from ...
I switched vscode explorer settings to use external terminal.
And this terminal setting to command prompt:
Terminal › Integrated › Default Profile: Windows
The default profile used on Windows. This setting will currently be ignored if either terminal.integrated.shell.windows or terminal.integrated.shellArgs.windows are set.
I have dotnet in the PATH (and it works in terminals and in vscode's terminal)
I restarted vscode, AND REINSTALLED the dotnettools "C# for Visual Studio Code (powered by OmniSharp)" extension. I went to the online store and from the right column under Resources I downloaded the ms-dotnettools.csharp-1.25.2#win32-x64.vsix to make sure I get the right one. And restarted vscode.
I tried this setting:
Omnisharp: Dotnet Path
Specified the path to a dotnet installation to use when "useModernNet" is set to true, instead of the default system one. This only influences the dotnet installation to use for hosting Omnisharp itself. Example: "/home/username/mycustomdotnetdirectory".
C:/Program Files/dotnet/sdk/6.0.405
And this setting:
Omnisharp: Sdk Path
Specifies the path to a .NET SDK installation to use for project loading instead of the highest version installed. Applies when "useModernNet" is set to true. Example: /home/username/dotnet/sdks/6.0.300.
C:/Program Files/dotnet/sdk/6.0.405
And restarted vscode. And now it says:
[ERROR] Error: Command failed: dotnet.exe --version
'dotnet.exe' is not recognized as an internal or external command,
operable program or batch file.
What? W H A T? lol
What could be wrong? Why isn't it saying where it expected to find it and what to do to locate it? Is there a setting to specify the dotnet.exe path to this C# extension? Does it need always-on internet or something? Does it have DRM? Does it need Edge installed? Wtf?🙂
🙃😭 I just need intellisense; and I've wasted 2h, on only microsoft-owned products.
#Microsoft 0/5 stars
Still don't know why it happens, but here's how to solve it:
The problem was from this: I like to keep all my visual studio code extensions as .vsix files locally in folders so I can remember and get them easily & offline. Sensible enough choice, and I had the correct ms-dotnettools.csharp-1.25.2#win32-x64.vsix for my platform.
But in VSCode, when I install this particular extension via VSIX, even though it succeeds, it can't find .net. If you instead install the extension "normally", ie via vscode's own download, it seems vscode does some extra configuration steps while installing, and probably sets the .net paths correctly or something. Because now it works.
So TL;DR: don't install ms-dotnettools.csharp via vsix, it seems bugged. 😶
Would love to see an answer explaining what's wrong / how to actually do via vsix; but I don't have any more time to debug this rn.

Mono TLS1.2 issues - btls-cert-sync "command not found"

Summary:
My company uses TargetProcess (TP) to track progress on open projects and we've created a relatively small bit of code that imports updates to TargetProcess.
Currently upon build submission, we spin up a debian docker image, with Mono pre-installed, and it runs our small .NET(C#) program to connect our updates to TP.
Repro:
It appears TP recently updated their API to only accept TLS1.2 connections, so we had to create a new docker image with Mono 4.8, the Alpha channel, on it (per this article).
The program still doesn't work out of the box with this new Mono installation on a docker image so we took a few steps: (following the prompting from Mono's Security FAQ)
// Made sure that the most current version ca-certificates-mono is installed
// and it seems to have been installed upon installation of mono 4.8
apt-get install ca-certificates-mono
// This should be an unnecessary step from what I read, but ran anyway
cert-sync /etc/ssl/certs/ca-certificates.crt
// lastly btls-cert-sync command, but can't seem to get it to not return
// "command not found" no matter wher I try running it
btls-cert-sync
Testing:
There seems to be a really helpful thread on how to test if your certs are formatted correctly. After running this test command in my docker image, I'm still seeing the failure message below.
MONO_TLS_PROVIDER=btls csharp -e 'Console.WriteLine (new System.Net.WebClient ().DownloadString ("https://www.howsmyssl.com/").IndexOf ("1.2"))'
// error message
System.Net.WebException: Error: TrustFailure (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED) ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSLroutines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
Any help or advice to get our instance of mono to accept TLS1.2 connections would be awesome.
btls-cert-sync is a shell script for btls-cert-sync.exe
Find btls-cert-sync.exe, normally installed in 4.8.0/lib/mono/4.8 and run it with mono:
mono btls-cert-sync.exe
As of mono 4.8 beta 3, btls-cert-sync seems to have been merged into cert-sync.
Do make sure that you have an up-to-date version of cert-sync as it is possible to get old versions of cert-sync still installed even if you have updated mono because the ca-certificates-mono package has not been updated (Linux).
If you look at the cert-sync output you will see
Mono Certificate Store Sync - version 4.8.0.0
...
Importing into legacy system store:
...
Importing into BTLS system store:
...

DebugAdapter bin folder not found on path "....vscode/extensions/ms-vscode.csharp-0.3.7/coreclr-debug/debugAdapters/OpenDebugAD7.exe."

OS: Windows 10
dotnet-cli:
Version: 1.0.0-beta-001598
Commit Sha: 7582649f88
This is after following the instructions here for C# debugging. Does it work yet for windows?
According to the error message, it looks like you did not install the C# extension as per the instructions https://microsoft.gallery.vsassets.io/items?itemName=ms-vscode.csharp
Open your command pallet and verify that the correct version is installed. Or, if it is, remove it and try installing again

Mono 3.4.1 isn't compiling correctly on the raspberry pi

I m trying to compile the latest Mono source from GIT (3.4.1) on the raspberry pi, i can make, and make install, but if i go to /usr/local/lib/mono i get only “2.0 compat-2.0 gac” folders and none for the other frameworks.
When i try to run:
pi#raspberrypi ~/testeMono $ mcs hello.cs
pi#raspberrypi ~/testeMono $ mono hello.exe
The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `/usr/local/lib/mono/4.5/mscorlib.dll' directory.
I have a initial mono installation that i got doing "sudo apt-get install mono-complete" (since i need mono to build mono) it's on /usr/lib/mono
i did 'make check' and here are the failed tests
420 test(s) passed. 6 test(s) did not pass.
Failed tests:
block_guard_restore_aligment_on_exit.exe
bug-10127.exe
finally_block_ending_in_dead_bb.exe
pinvoke2.exe
pinvoke3.exe
winx64structs.exe
make[5]: *** [runtest] Error 1
make[5]: Leaving directory `/home/pi/mono/mono/tests'
make[4]: *** [testjit] Error 2
make[4]: Leaving directory `/home/pi/mono/mono/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/home/pi/mono/mono/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/pi/mono/mono/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/pi/mono/mono'
make: *** [check-recursive] Error 1
Any help trying to debug what's wrong is welcome, since i don't know where should i look.
I would add these questions to comment, but don't have enough reputation.
what is the output of ./autogen.sh at the end? Look at the libraries section. Do you have .NET 4.0 and .NET 4.5 'yes' in this section? If they are 'no', try run ./autogen.sh --with-profile4=yes --prefix=your_prefix
Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes
why do you choose to install in /usr/local, when your system mono is located in /usr? You'll have two mono installation in different directories. This is useful, when you what to use parallel mono environments, but as far as I understand, you just want update mono to the latest version. I use --prefix=/usr in this case, to avoid issues of finding libraries in PATH.
these failed tests mean that some of mono functionality (related to PInvoke) won't work correctly on your platform but in general mono will work as expected (because all other tests were passed)

How do I deploy a Mono Winforms Application to Suse Linux 11.0 Server Enterprise?

Is there a way to make a simple installer that includes the necessary runtimes and dependency packages, and creates an icon in the OpenSuse menu, so the application will "just work?"
The actual application is just an executable (.EXE) and a handful of support files (mostly XML and CSV).
I already have the application successfully building and executing in MonoDevelop 2.0.
I originally tried to install the Mono Runtime via zypper from the following repository http://ftp.novell.com/pub/mono/download-stable/openSUSE_11.0, but quickly got bogged down in missing package dependencies.
This is what happens when I try to use zypper to install the Mono runtime:
linux-lkfu:~ # zypper addrepo http://ftp.novell.com/pub/mono/download-stable/SLE_11 mono-stable
Adding repository 'mono-stable' [done]
Repository 'mono-stable' successfully added
Enabled: Yes
Autorefresh: No
URI: http://ftp.novell.com/pub/mono/download-stable/SLE_11
linux-lkfu:~ # zypper refresh --repo mono-stable
Retrieving repository 'mono-stable' metadata [done]
Building repository 'mono-stable' cache [done]
Specified repositories have been refreshed.
linux-lkfu:~ # zypper dist-upgrade --repo mono-stable
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Nothing to do.
linux-lkfu:~ #
Notice the last line before the prompt that says "Nothing to do." I don't think it's doing anything.
One option is to buy mono support for SLES 11 from Novell. That will grant you a tested, supported and working mono repository.
If not you have to use the SLES repositories. For mono it's http://ftp.novell.com/pub/mono/download-stable/SLE_11
This should do it:
zypper addrepo http://ftp.novell.com/pub/mono/download-stable/SLE_11 mono-stable
zypper refresh --repo mono-stable
zypper dist-upgrade --repo mono-stable
If you have Visual Studio, you can try Mono Tools for Visual Studio, which provides tooling to make this easy. It is fully functional for 30 days.
http://go-mono.com/monotools/
that depends on how you plan to package them up. Either you manually create (deb for Debian and Ubuntu, rpm for Fedora and openSUSE, or anything else).
Personally, I think at first it is acceptable to simply add a .sh to your ZIP package and ask the end users to execute it for dependency checking, installing, and so on.
Then you can learn about the packaging methods.

Categories