Ticket #211 (reopened enhancement)

Opened 4 years ago

Last modified 2 years ago

Create a static debugging build to help people

Reported by: valerio Owned by: diederik
Priority: critical Milestone: kmess-3.0
Component: Deployment Version: 1.5.1
Keywords: Cc:

Description (last modified by sjors) (diff)

We need to be able to give away to users a full-debug build with everything statically linked, to run directly without installation.

This would greatly improve our debugging process.

The static debug version could maybe log everything into a file instead, rather than into console, which could be placed in the user's home - (possibly even with contact emails/IPs obfuscated, for privacy reasons?) - so that we could request reporters to send us that file.

Change History

Changed 4 years ago by diederik

  • component changed from Other to Build process

Changed 4 years ago by valerio

  • status changed from new to closed
  • resolution set to invalid

KDE Libs can't be statically linked. Closing.

Changed 4 years ago by diederik

Statically linking isn't a solution indeed, however, we could still release a binary which you can run everywhere. We've did that with KDE 3 too in combination with Autopackage.

If a binary is compiled against a clean KDE4 code base, and with lower glibc symbols it will very likely run at every KDE4 system.

Changed 4 years ago by diederik

  • status changed from closed to reopened
  • resolution invalid deleted

Changed 4 years ago by valerio

Ok, it's a bit different than the solution I had originally thought, but it's fine nevertheless. I'm not quite capable of performing glibc magic or the like, so I drop the ball here ;D

Changed 3 years ago by valerio

I didn't think about it beforehand.. but what about Klik?

We could also release KMess in a Klik package.

Changed 3 years ago by diederik

Hmm that would be a nice idea too.. I used to maintain the KMess klik package too.

So far there are IMHO two solutions:

  • Offer a click package, this contains the full bundle of resource files, etc..
  • Offer a binary, with nothing else. People who already have KMess installed can run it, and it would use the resource files they already installed.

Changed 3 years ago by valerio

  • milestone changed from kmess-2.0 to kmess-2.1

Changed 2 years ago by sjors

  • description modified (diff)

But there can never be a static build while we build against KDE always. This also means that the build for Mac and Windows will always be handicapped. I think we should investigate in the same solution as Quassel uses: use KDE, but make it possible for the user to turn it off for QtGui-only, and lose some features.

Also, if we want full static builds, that means we've got to have a static build for Qt, a static build for QCA, and we need the OSSL plugin compiled in some way. Or, alternatively, we find out a way to skip that plugin altogether. Is there *any* way in which we can do that? What exact algorithms do we need? There must be a better way to get it in KMess, that OSSL plugin is really a support hell and it makes this static build impossible.

Note: See TracTickets for help on using tickets.