Print

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

[mifki]

Well, you're definitely not using that in 0.43.03. Try gcc-4.5?

And do -v, not --version.

[majiin]

Are there more libraries I should include/not include?  I don't know what the best set is for 64 bit Linux.

I think the standard libraries are ok, no need to change what was working for 32bit build for such a long time. There are so many Linux distros out there, even if I can safely remove df_linux/libs/libstdc++.so.6 and libgcc_s.so.1 there is no guarantee it will work for others. Maybe users of more popular distros like Debian or Ubuntu should voice their opinion.

I was just surprised that 64bit Linux DF complains about missing OpenAL while 32bit DF don't (OpenAL 32/64 was not installed at the time of testing)

[Thief^]

no appreciable speed difference in performance by using a smaller integer size than the CPU's bitness

Sure it is only a few clock cycles. A few clock cycles times 200 billion operations is very noticeable. I always advocate learning and applying best practices and making them habit. Note that I suggested it for counter variables that are likely to be short lived registers instead of stored in RAM, which is where the greatest speed benefit is found.

It would be good advice, if there was actually a multiple clock cycle difference in ops by register width. But there is not. Most integer ops are single cycle these days, regardless of operand size.

The only speed difference I know of is with array indexing, where the operand has to be widened to the width of the pointer before indexing instructions can be used. But:
1: that's a single cycle op
2: If there's a load or move instruction, it can be included at 0 additional cost
3: The optimiser is capable of automatically widening loop counters, anyway.

[Toady One]

Here's the script building a file:

g++ -o src/g_src/enabler_input.o -c -std=gnu++0x -Flibs -Ilibs/SDL.framework/Headers -Dunix -DGLEW_STATIC -O2 -fomit-frame-pointer -s -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -dead_strip -Ifmodexinclude -Iglext src/g_src/enabler_input.cpp
scons: done building targets.
Build complete, DF in df_osx.tar.bz2

and me immediately after

g++ -v

Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5490)

[mifki]

Target: i686-apple-darwin9

Means it doesn't have 64bit support. So you'll need to install something newer (if it turns out you're indeed using this gcc).

[lethosor]

Strange, the libstdc++ you're distributing with DF has strings like this embedded in it:

Code: [Select]

/Users/tarnadams/gcc/gcc-4.5.1/libstdc++-v3/libsupc++/cxxabi.h
Removing that libstdc++ causes DF to fail to start, which means you're using something newer than GCC 4.2 (which is my system's default). (Basically, you need a libstdc++ that corresponds to the GCC version used to compile DF, or a newer libstdc++ - if you were using GCC 4.0, there would've been no need to distribute libstdc++ in the first place.)

Is there a g++-4.5 or g++45 in your path? (Try running e.g. "g++-4.5 --version", or typing "g++" in a terminal window and pressing tab twice for a list of completions.) It's possible that scons is trying to save space by displaying "g++" instead of the actual executable name, or that there's a newer g++ somewhere else (which should show up with "which -a g++").

If not, try looking in /Users/tarnadams/gcc/gcc-4.5.1/ (maybe /Users/tarnadams/gcc/gcc-4.5.1/bin?) for a g++ executable.

[Toady One]

So...  g++ with tab x2 shows g++ g++4.0 and g++4.2.  Then when I did which -a g++, it gave me /usr/bin/g++ and /usr/local/bin/g++.  The first one was 4.0.1, but the second one was 4.5.1.  So I guess we're managing to get through to 4.5.1 in the script somewhere.  I don't know where in there it picks out the right one.

So there might be additional hope.

[mifki]

So there might be additional hope.

Anyway, if -v says Target: x86_64 then you're good to go, if not then not.

[lethosor]

Okay, that's probably where the build in ~/gcc/gcc-4.5.1 installed to. What does "/usr/local/bin/g++ --version" give you?

Edit: or "-v" instead of "--version". And compiling a test file with -m64 is probably the most definitive way of determining whether it's 64-bit capable, anyway.

[SilverSynch]

I think the standard libraries are ok, no need to change what was working for 32bit build for such a long time. There are so many Linux distros out there, even if I can safely remove df_linux/libs/libstdc++.so.6 and libgcc_s.so.1 there is no guarantee it will work for others. Maybe users of more popular distros like Debian or Ubuntu should voice their opinion.

This is actually incorrect, having new, compatibility breaking versions of libraries under the same name as previous versions is extremely bad form in Linux (which does result in cluttered managers with lots of packages under similar names). Symlink libblargh.so.1 will always link to a library under version 1, libblargh.so.2 will always link to a library under the new, compatibility breaking version 2.

Even then, if any Linux distro actually goes against standard library names, they would have quite the sore user-and-devbase on their hands, because developers do NOT like having to make special versions for each distro (they will make special packages, but that's for a another reason entirely).

[Max™]

Worked fine here on Arch, though I got something which I think was a Kwin error.

Code: [Select]

(Dwarf_Fortress:23514): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",

(Dwarf_Fortress:23514): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
Didn't hurt anything though, just the message. I'll test more later, gonna rest a bit.

[jecowa]

Target: i686-apple-darwin9

Means it doesn't have 64bit support. So you'll need to install something newer (if it turns out you're indeed using this gcc).

Right now Toady is on Mac OS 10.5 Leopard. I think 10.6 Snow Leopard is the first version of Mac OS X with full 64-bit support. (Snow Leopard has a 64-bit kernel.) It's also the newest version I would recommend running on a computer with less than 4 GB of RAM (i.e. Toady's Mac mini). Snow Leopard is the ultimate version for older machines. And as Miuramir indicated, running an older version of OS X is needed in order to support players with older versions of OS X.

[mifki]

Right now Toady is on Mac OS 10.5 Leopard. I think 10.6 Snow Leopard is the first version of Mac OS X with full 64-bit support. (Snow Leopard has a 64-bit kernel.) It's also the newest version I would recommend running on a computer with less than 4 GB of RAM (i.e. Toady's Mac mini). Snow Leopard is the ultimate version for older machines.

On OS X, running 64bit kernel != being able to run 64bit apps. 10.5 has 64bit libraries.
But I agree, 10.5 is a transitional version, and 10.6 would be the right choice.

And as Miuramir indicated, running an older version of OS X is needed in order to support players with older versions of OS X.

Not true.

[SilverSynch]

Worked fine here on Arch, though I got something which I think was a Kwin error.

Code: [Select]

(Dwarf_Fortress:23514): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",

(Dwarf_Fortress:23514): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
Didn't hurt anything though, just the message. I'll test more later, gonna rest a bit.

That's just GTK crying about the Adwaita theme missing. It's supposed to be a default theme though, so I wonder how you did that.

[lethosor]

It's worth noting that Toady would have to pay for 10.6. A quick search for "macmini2,1" turns up two models, both with 64-bit CPUs and only officially capable of running up to OS X 10.7, so assuming that's accurate, I don't see much need for Toady to upgrade if his current system is capable.