Question to the Linux users

[Roland Melkert]

Anyone here a seasoned Linux desktop user (with some programming experience)?

With LDCad 1.0 beta out, I'm playing around with getting a Linux version going. But having only experience with Linux server systems I'm a bit lost with all the desktop options out there.

I'm currently downloading Ubuntu wubi (I use Ubuntu server for work so this is at least some what familiar) to get a look, but maybe people think I should use something other for the base development environment.

The goal is to get a (set of) pre compiled binaries to add to the LDCad download site covering most used desktop stuff. I'm figuring when it compiles in Ubuntu 11, it would also go in most other recent distro's.

I'm just hoping to avoid pitfalls by using any info people can give me.

ps: this might be more of a 'dev' thing, but there is no section for that (yet).

[Tim Gould]

Hi Roland,

I used Ubuntu quite regularly. I suspect it's the most commone distro although some use Gnome and others KDE (Kubuntu) for the desktop.

If possible I'd suggest you focus on Ubuntu 10.04 as it's the long-term support version meaning it'll be around for a while.

That said, I think if you can get it to compile on one it'll probably compile on most.

Tim

[Roland Melkert]

Thanks for the info, I'm going with Ubuntu 10.04 for the initial port, and hoping to get it to work for 11 as well.

This weekend's work seems to pay off, cause it compiled with far less problems then I was expecting. It's mighty unstable though (something thread related is going weird).

It's rendering nearly the same as on windows (see screen cap), but it uses the mesa (software) render-er (virtual machine) so it's ridiculously slow

Screencap

It's also having some Linux file name issues, but far less then I was expecting.

So all with all I might get a stable Linux version online in a month or two.

[Travis Cobbs]

One huge problem with Linux in general is shared libraries. In theory, the Linux solution to the problem is better than Microsoft's DLL Hell, but in practice, they cause endless pain and suffering for both you as a developer and your users. Different distros come with different ones standard, and different versions of the same distro have different incompatible versions of the same shared libraries (with no access to older ones short of the user building by hand). So, after much cursing, my opinion at this point is that for binary distributions, the more static linking you can perform, the better, even though this goes against software engineering principles.

This makes the binary bigger, and it makes it use more memory on the machine (because shared libraries themselves share executable memory between processes, and static ones don't), but if you actually use shared libraries like they're designed to be used, you're locking your release into a small subset of Linux distributions, and it's almost guaranteed that a binary you release today won't work on any standard Linux distribution in 2 years time (which is unforgivable of Linux distributions, in my opinion, but appears to be standard practice). In particular, all of the following libraries have caused me grief with LDView:

• Mesa
  
• Qt
  
• Boost
  
• PNG
  
• JPEG
  

Having said all that, you're probably better of not using a static version of Mesa, because that may interfere with proper hardware acceleration. But if you use any of the others, then if you can get them to compile statically linked, I'd suggest doing so.

[Roland Melkert]

Thanks for the insight,

I've setup the project to use as little 3rd party stuff as possible. Most is own code (like string handling) using std functions only. So the current version only needs:

wxWidgets (gdi gui)
boost (Only threading and mutex stuff, wx already uses pthread, but I want to keep the gui and 'core' separate.)
zlib & libpng (texture loading)
glew (OpenGL headers)

In the windows version I managed to statically link to all (hence the 7MB exe).

Current linux version uses only wxWidgets statically at the moment (you can check using console command ldd, what deps a executable has.) But this is because I haven't tried optimizing the linking make rule jet.

I'm not sure but I aslo think wxWidgets has some 'via via' dependencies but those should be less of a problem, cuase wxWidgets has been designed for static linking.

Haven't (dare) tried running the executable in a clean environment jet though. I first want to make sure all functionality is working correctly.

I probably could get rid of the z and png deps by writing my own (very basic) png loader (It only has to handle 24/32 bit files anyway) or use something more basic (like tga), but haven't found the time/motivation for that jet.

ps: mesa is only used at the moment because it's the default OpenGL render in the VMWare machine I'm using at the moment. The executable should use whatever is available without recompile.

[Travis Cobbs]

It sounds like you're already aware of many of the problems. Please note that both zlib and libpng can be easily compiled into static libraries, so even if you can't track down pre-built static binaries, it's quite easy to create them. The downside of doing it that way is that you don't get future security fixes, which would automatically happen when you use shared libraries. The upside is that your executable will continue to work even if the OS decides to update to a new major version of these libraries without providing the old version as a fallback (which happened to me with libjpeg). However, the security issue should only be a potential problem if you load user-specified PNG files (which I would suspect you wouldn't do at the moment). That could happen in the future, though, if a texture mapping extension to LDraw ever becomes ratified.

[Lars Ivar Igesund]

Roland,

I'm not sure I agree all that much with Travis on the big issue with libraries, although he has a point if you require to provide all binaries yourself.

Binary compatibility is usually strong, because a lot of the relevant libraries are standardized through the Linux Standard Base. In particular, if you use a release like Ubuntu 10.04, then your program most likely will work with later releases too. WxWidgets is not part of the LSB though.
Minor libraries like zlib and libpng change their API even less frequently.

Note that you probably won't wish to link Mesa statically, as that is not likely to provide you with proper access to hardware acceleration.

When this is said - is the source available? Is LDraw an open source project? If it is, it is possible to hope for distribution specific maintainers taking up the task to provide up-to-date packages for various platforms.

[Roland Melkert]

Thanks for your thoughts.

I currently have a stable binary with all my 3rdparty used stuff statically linked ( 5MB ). It runs on clean Ubuntu 10.4, Fedora 14 (under vmware) and Ubuntu 11.10.

It turns out my biggest problems are with OpenGL during non virtual boots at the moment, cause the Open source Radeon driver seems to ignore the two sided lighting model. The AMD prop driver seems to render all fine, but it has other short comings (like it trashes my dual monitor setup, and won't let me reuse the front buffer correctly).

Both problems can be solved by alternatives (own vertex shader for the dual lighting, FBO for the front buffer image recycling), but I was kinda hoping on a 'easy' port.

Also nether are problems on the Windows version and the solutions increase minimum requirements to be enabled.

[Lars Ivar Igesund]

I don't seem to have any notable issues with AMD/ATI's proprietary driver and a two-monitor setup. Maybe this is caused by the differences in in how X and Windows handles this? I think X gives you more alternatives in terms of desktops and such.

I have generally experienced that the Radeon driver is not very usable. As for the frontbuffer issue, that is not something I have tried. I use shaders for everything in what I do at work, but it is not the most advanced type of application (in terms of shininess).

[Roland Melkert]

I think I found a solution for the dual screen issue (I have to increase the maximum virtual desktop size), but I havn't tried that yet.

Yes a custom shader for rendering the triangles in their current state shouldn't be to hard to write (could pretty much use the examples in the OpenGL bible), but when I'm going to replace the stock shader I also want to explore things like rendering rubber, metal and plastic noticeably different. I'm also playing with the thought of adding (optional) per pixel lighting and shadows just to keep me busy during the upcoming holidays

The front buffer issue, isn't a real bug also, cause the standard does not guarantee it's state upon next rendering cycle. But so far this trick worked on most systems in order to just copy e.g. the partbin panel content instead of re rendering it when only the editor window changed (I'm using a single context).