Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Toady One]

I have four cc1plus going, %MEM is ~20 for each.  Am I just running out of RAM in the new setup?

edit: I changed the build script to use just one core, and now it is going through the files at around 50% mem usage.  We'll see what happens when it hits a bad one.

edit: Yeah, it's bumping up against my 2GB and going to swap on occasion.  I'm going to let it run through to the end and see if we have any actual error messages at the link/libgraphics phase.  I'm guessing it'll take about an hour to compile everything, but I'm not sure since it might hit a bump later on.

edit: made it to libgraphics (this is the 32 bit attempt)

Code: [Select]

g++ -o src/libgraphics.so -Wl,--as-needed -Wl,-rpath=\$ORIGIN -m32 -pthread -shared src/g_src/enabler.os src/g_src/basics.os src/g_src/command_line.os src/g_src/graphics.os src/g_src/init.os src/g_src/interface.os src/g_src/win32_compat.os src/g_src/music_and_sound_openal.os src/g_src/random.os src/g_src/textlines.os src/g_src/keybindings.os src/g_src/ViewBase.os src/g_src/textures.os src/g_src/files.os src/g_src/enabler_input.os src/g_src/GL/glew.os src/g_src/KeybindingScreen.os src/g_src/resize++.os src/g_src/renderer_offscreen.os src/g_src/ttf_manager.os src/g_src/find_files_posix.os -Llibs -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -lSDL -lSDL_image -lGLU -lz -lSDL_ttf
/usr/bin/ld: cannot find -lgtk-x11-2.0
/usr/bin/ld: cannot find -lgdk-x11-2.0
/usr/bin/ld: cannot find -latk-1.0
/usr/bin/ld: cannot find -lgio-2.0
/usr/bin/ld: cannot find -lpangoft2-1.0
/usr/bin/ld: cannot find -lpangocairo-1.0
/usr/bin/ld: cannot find -lgdk_pixbuf-2.0
/usr/bin/ld: cannot find -lcairo
/usr/bin/ld: cannot find -lpango-1.0
/usr/bin/ld: cannot find -lfontconfig
/usr/bin/ld: cannot find -lgobject-2.0
/usr/bin/ld: cannot find -lglib-2.0
/usr/bin/ld: cannot find -lfreetype
/usr/bin/ld: cannot find -lSDL
/usr/bin/ld: cannot find -lSDL_image
/usr/bin/ld: cannot find -lGLU
/usr/bin/ld: cannot find -lSDL_ttf
collect2: error: ld returned 1 exit status
scons: *** [src/libgraphics.so] Error 1
scons: building terminated because of errors.
Do I need more packages?  I have the ones from before (libsdl1.2-dev etc.).  Or is it something else?

[mifki]

Do I need more packages?  I have the ones from before (libsdl1.2-dev etc.).  Or is it something else?

Basically yes, you'll need to install dev packages with both :i386 and :amd64 suffixes. The problem is that it's sometimes hard to understand what package contains the needed library.
There's likely a command to find a package that provides a filename, but you can just do apt-cache search <libname> and choose something with -dev suffix that looks most appropriate.

[Toady One]

libsdl1.2-dev:i386 : Depends : libcaca-dev:i386 but it is not going to be installed
Unable to correct problems, you have held broken packages.

[mifki]

libsdl1.2-dev:i386 : Depends : libcaca-dev:i386 but it is not going to be installed
Unable to correct problems, you have held broken packages.

Oh I see (i386 dev packages conflict with amd64 dev packages).. But I have no idea how to fix it. Probably there's a way to set up a multiarch dev environment properly (like set up virtual environments with different architectures), but I don't know.
Unless someone comes and tells how to do that and it's easy, what I'd do in this case is simply have two VMs with i386 and amd64 Ubuntu and use them to build separately. You can use free VirtualBox on your Windows machine for VMs or DigitalOcean, where you can create a VM in just a minute with any distro/arch and then destroy it. Use Vagrant as I outlined below.

[lethosor]

The closest thing to an answer I could find was "some packages can't be installed for multiple architectures at the same time". I don't know if this is the case with libcaca-dev, though. Does just installing libsdl-1.2:i386 work? It may be that the different headers are conflicting but the libraries themselves aren't (but I'm really not an expert on this).
Failing that, if you need to use a VM, running 64-bit Linux natively and 32-bit Linux in a VM (hosted on your Windows machine, if that has more memory available) would probably be more efficient than the other way around. Not sure if an online VM is something you'd want to use to compile DF.

[mifki]

Here's an easyway to get 32bit dev environment on your Linux machine without manually configuring VMs, etc.

Code: [Select]

wget https://releases.hashicorp.com/vagrant/1.8.4/vagrant_1.8.4_x86_64.deb
dpkg -i vagrant_1.8.4_x86_64.deb
apt-get install virtualbox

mkdir df_32 && cd df_32
vagrant init ubuntu/trusty32
vagrant up

Then you do "vagrant ssh" and you're logged into a 32bit machine AND your df_32 folder is accessible from inside the machine as /vagrant. And you can use your physical Linux machine itself for 64bit builds, by removing 32bit libraries and installing just 64bit.

[nop]

vagrant is an old day, use docker for setting up 32bit environment and compiling

@toady
it is a crazy idea, but what about a twitch stream 'let us compile dwarf fortress' with the help from the chat?

[mifki]

vagrant is an old day, use docker for setting up 32bit environment and compiling

Possible but more difficult to configure and use.

[Toady One]

Does just installing libsdl-1.2:i386 work? It may be that the different headers are conflicting but the libraries themselves aren't (but I'm really not an expert on this).

"libsdl-1.2:i386" wasn't there, and "libsdl1.2:i386" was referenced by other packages but 'missing or obsolete'.  I'm not sure how you just get the library.

I'm trying a 64 bit build now to see how that works out in the link stage (1 core compiling seems to be squeaking through).  I'll worry about VMs for 32 after that, if that's the way to go.

[PatrikLundell]

I've done a lot of world generation using the 64 bit version and got a crash yesterday (probably not specifically related to 64 bit, but just the same as occasionally happened earlier as well). I've got the event report info and a crash dump. Are these of interest? If so, I can upload the dump and provide a link.

[Toady One]

Linux 64 linked, but I get a compression error trying to run it.  Wrong zlib maybe?  Not sure how to check which one it is using.  Or I have some 64 bit problem with the file loading code itself that bothers linux and not windows.

I've done a lot of world generation using the 64 bit version and got a crash yesterday (probably not specifically related to 64 bit, but just the same as occasionally happened earlier as well). I've got the event report info and a crash dump. Are these of interest? If so, I can upload the dump and provide a link.

Unfortunately, I don't know how to get anything out of those, and it's compounded by the discussion in the thread about worlds not generately the same way for the same seed.  I should probably fix up that situation as soon as I can get to it.

[PatrikLundell]

I was afraid they'd be of no use, that's why I asked first. The non deterministic world generation issue is not completely new, but last time I encountered it I couldn't repeat the problem with the latest (at that time) version, and it didn't happen often.

[Thief^]

I've done a lot of world generation using the 64 bit version and got a crash yesterday (probably not specifically related to 64 bit, but just the same as occasionally happened earlier as well). I've got the event report info and a crash dump. Are these of interest? If so, I can upload the dump and provide a link.

Unfortunately, I don't know how to get anything out of those, and it's compounded by the discussion in the thread about worlds not generately the same way for the same seed.  I should probably fix up that situation as soon as I can get to it.

For crash dumps from windows, you just open them in visual studio and press "run" and it replicates the same crash that actually happened. You'll start off just getting the error message and access to the assembly I think, but if you can point it at the original pdb file and source code of the release it'll give you a full debugger experience.

[Max™]

We need to download some more RAM for Toady, clearly.

[int_ua]

Another option for building 32bit on a 64bit Ubuntu is to use mk-sbuild + schroot: http://askubuntu.com/a/216670/20275
Allowing to work with the same home directory is currently omitted there, check https://wiki.ubuntu.com/SimpleSbuild#Mount_your_home_dir
It should avoid overhead of creating a whole new install (it will download only the packages that differ, AFAIU) and running a VM.