Discussion
Loading...

#Tag

  • About
  • Code of conduct
  • Privacy
  • Users
  • Instances
  • About Bonfire
Sobex
@Sobex@social.sciences.re  ·  activity timestamp 2 days ago

#llvm #clang help.

Anyone here knows what the difference is between builtin and standard include locations for LLVM/Clang ?

For some reason my LLVM install is using the C++ headers from the LLVM install tree and the system libc++, and I'd need it to using the system C++ headers for things to work.

Boost to fix compilation issues.

  • Copy link
  • Flag this post
  • Block
Martin Bishop
@toomanysecrets@mastodon.social  ·  activity timestamp 4 days ago

The #Linux #kernel authorities are currently discussing whether to enable support for Microsoft C (MSVC) language extensions. Sounds like heresy? It turns out, this is about the growing importance of the #Clang compiler. The patches under review do not aim to compile Linux with Microsoft’s cl.exe compiler. Instead, they enable the kernel to take advantage of Clang’s ability to operate in a Microsoft-compatible dialect. Why would Linus Torvalds want that?
1/3

Martin Bishop
@toomanysecrets@mastodon.social replied  ·  activity timestamp 4 days ago

1. #Android kernels use #LLVM / #Clang almost exclusively. Clang supports two dialects: #GNU #C mode and #MSVC mode. Supporting both dialects means the kernel can build and test under more configurations.
2/3

  • Copy link
  • Flag this comment
  • Block
Martin Bishop
@toomanysecrets@mastodon.social  ·  activity timestamp 4 days ago

The #Linux #kernel authorities are currently discussing whether to enable support for Microsoft C (MSVC) language extensions. Sounds like heresy? It turns out, this is about the growing importance of the #Clang compiler. The patches under review do not aim to compile Linux with Microsoft’s cl.exe compiler. Instead, they enable the kernel to take advantage of Clang’s ability to operate in a Microsoft-compatible dialect. Why would Linus Torvalds want that?
1/3

  • Copy link
  • Flag this post
  • Block
Stefano Marinelli boosted
@modev
@modev@mastodon.bsd.cafe  ·  activity timestamp 2 weeks ago

This is a simple space game.
I am making it in my spare time for fun and learning.
Feel free to use it as template for your own things.

https://sr.ht/~modevstudio/mospace/

#gamedev #clang #raylib #box2d #flecs

mospace: Simple space game crafted with C, box2d, raylib, flecs.

Spaceship shooting into enemies, asteroids.
Spaceship shooting into enemies, asteroids.
Spaceship shooting into enemies, asteroids.
  • Copy link
  • Flag this post
  • Block
@modev
@modev@mastodon.bsd.cafe  ·  activity timestamp 2 weeks ago

This is a simple space game.
I am making it in my spare time for fun and learning.
Feel free to use it as template for your own things.

https://sr.ht/~modevstudio/mospace/

#gamedev #clang #raylib #box2d #flecs

mospace: Simple space game crafted with C, box2d, raylib, flecs.

Spaceship shooting into enemies, asteroids.
Spaceship shooting into enemies, asteroids.
Spaceship shooting into enemies, asteroids.
  • Copy link
  • Flag this post
  • Block
Stefano Marinelli boosted
Peter N. M. Hansteen
@pitrh@mastodon.social  ·  activity timestamp 3 months ago

C++ library update in -current https://www.undeadly.org/cgi?action=article;sid=20250822171538 #openbsd #cplusplus #c++ #programming #development #library #clang #freesoftware #libresoftware

  • Copy link
  • Flag this post
  • Block
Peter N. M. Hansteen
@pitrh@mastodon.social  ·  activity timestamp 3 months ago

C++ library update in -current https://www.undeadly.org/cgi?action=article;sid=20250822171538 #openbsd #cplusplus #c++ #programming #development #library #clang #freesoftware #libresoftware

  • Copy link
  • Flag this post
  • Block
Paolo Amoroso
@amoroso@oldbytes.space  ·  activity timestamp 5 months ago

An interesting remark in Josep Bigorra's post on why Scheme can be used for production work:

There’s only one truly universal ecosystem: the C ecosystem. Dynamic language modules are often just bindings to existing C libraries.

https://jointhefreeworld.org/blog/articles/lisps/scheme-and-lisps-are-great-for-production/index.html

#lisp #scheme #clang

  • Copy link
  • Flag this post
  • Block
Felix Palmen :freebsd: :c64:
@zirias@mastodon.bsd.cafe  ·  activity timestamp 5 months ago

I need help. First the question: On #FreeBSD, with all ports built with #LibreSSL, can I somehow use the #clang #thread #sanitizer on a binary actually using LibreSSL and get sane output?

What I now observe debugging #swad:

- A version built with #OpenSSL (from base) doesn't crash. At least I tried very hard, really stressing it with #jmeter, to no avail. Built with LibreSSL, it does crash.
- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM
- The thread sanitizer finds nothing to complain when built with OpenSSL
- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)
- It even complains when running with a single-thread event loop.
- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.
- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless
- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output 😳

Felix Palmen :freebsd: :c64:
@zirias@mastodon.bsd.cafe replied  ·  activity timestamp 5 months ago

For two days straight, I just can't reproduce #swad #crashing with *anything* in place (#clang #sanitizer instrumentation, attached #debugger like #lldb) that could give me the slightest hint what's going wrong. 😡

But it *does* crash when "unobserved". And it looks like this is happening a lot sooner (or, more often?) when using #LibreSSL ... but I also suspect this could be a red herring in the end.

Situation reminds me of my physics teacher back at school, who used to say something in german I just can't ever forget:

"Wer misst, misst Mist."

Feeble attempt in english would be "the one who measures measures crap", it was his humorous way to bring one consequence of #Heisenberg's indeterminacy principle to the point. And indeed, #debugging computer programs always suffers from similar problems...

  • Copy link
  • Flag this comment
  • Block
Felix Palmen :freebsd: :c64:
@zirias@mastodon.bsd.cafe  ·  activity timestamp 5 months ago

I need help. First the question: On #FreeBSD, with all ports built with #LibreSSL, can I somehow use the #clang #thread #sanitizer on a binary actually using LibreSSL and get sane output?

What I now observe debugging #swad:

- A version built with #OpenSSL (from base) doesn't crash. At least I tried very hard, really stressing it with #jmeter, to no avail. Built with LibreSSL, it does crash.
- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM
- The thread sanitizer finds nothing to complain when built with OpenSSL
- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)
- It even complains when running with a single-thread event loop.
- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.
- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless
- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output 😳

  • Copy link
  • Flag this post
  • Block
Log in

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances
Bonfire social · 1.0.0 no JS en
Automatic federation enabled
  • Explore
  • About
  • Members
  • Code of Conduct
Home
Login