Print

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

[ohgoditburns]

I haven't been able to get anything I compile myself to work. Always get some message like:

Code: [Select]

dyld: lazy symbol binding failed: Symbol not found: __ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm
  Referenced from: ./hack/libdfhack.dylib
  Expected in: /Users/rbrady/df/libs/libstdc++.6.dylib

There are no errors in compiling, but plenty of warnings about how variable X is too small to hold all values of Y.

Obviously, since I was able to use the one compiled earlier by nopenope, this is a problem on my end. Anyone know how to resolve the problems with libstdc++.6.dylib?

[fricy]

I haven't been able to get anything I compile myself to work. Always get some message like:

Code: [Select]

dyld: lazy symbol binding failed: Symbol not found: __ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm
  Referenced from: ./hack/libdfhack.dylib
  Expected in: /Users/rbrady/df/libs/libstdc++.6.dylib
There are no errors in compiling, but plenty of warnings about how variable X is too small to hold all values of Y.
Obviously, since I was able to use the one compiled earlier by nopenope, this is a problem on my end. Anyone know how to resolve the problems with libstdc++.6.dylib?

Not quite the same error, and it may not have anything to do with the error, but I'd check if you have proper X11 on your system. Especially if you want to compile on 10.8/10.9. Plus the 40.08 osx memory structures are not yet in the official repo, you need to pull them from lethosor's.

[Philii]

DFHack 0.40.08-r0 Windows
In trade menu, press [q] to search and Crash.

[mifki]

I haven't been able to get anything I compile myself to work. Always get some message like:

Code: [Select]

dyld: lazy symbol binding failed: Symbol not found: __ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm
  Referenced from: ./hack/libdfhack.dylib
  Expected in: /Users/rbrady/df/libs/libstdc++.6.dylib

There are no errors in compiling, but plenty of warnings about how variable X is too small to hold all values of Y.

Obviously, since I was able to use the one compiled earlier by nopenope, this is a problem on my end. Anyone know how to resolve the problems with libstdc++.6.dylib?

What compiler are you using? If newer than gcc 4.5 then you need to copy libstdc++.6.dylib from compiler lib to df (not from /usr/lib !).

[ohgoditburns]

gcc 4.8. Brew errors out if I try to install 4.5. Not sure why. I think brew puts stuff in usr/local/lib, so I'll try that. Thanks!

[mifki]

Plus the 40.08 osx memory structures are not yet in the official repo, you need to pull them from lethosor's.

--offtopic below--
That's what I hate git/github for. Before cool-distributed-trendy-git-github people gained write access to a single repo and just worked there together. Now they're forking and forking, right now we have at least five more or less active dfhack repos, nobody knows which one to use at a given point in time and when changes going to be merged into the "main" repo.
--offtopic end--

[mifki]

gcc 4.8. Brew errors out if I try to install 4.5. Not sure why. I think brew puts stuff in usr/local/lib, so I'll try that. Thanks!

For brew and 4.9 the path is /usr/local/Cellar/gcc49/4.9.0/lib/gcc/x86_64-apple-darwin13.2.0/4.9.0/i386/libstdc++.6.dylib don't forget the folder in bold.

[Nopenope]

--offtopic below--
That's what I hate git/github for. Before cool-distributed-trendy-git-github people gained write access to a single repo and just working there together. Now they're forking and forking, right now we have at least five more or less active dfhack repose, nobody knows which one to use at a given point in time and when changes going to be merged into the "main" repo.
--offtopic end--

This. I don't think I'm the only one wanting to be bleeding-edge and it's just silly to have to fetch stuff from unofficial repos because of all these forks. Hardly anyone knows which one will compile, which one will run, which one is Linux/OS X compatible (since these are usually given less priority), etc. Even the AUR contains outdated versions.

[Roses]

--offtopic below--
That's what I hate git/github for. Before cool-distributed-trendy-git-github people gained write access to a single repo and just working there together. Now they're forking and forking, right now we have at least five more or less active dfhack repose, nobody knows which one to use at a given point in time and when changes going to be merged into the "main" repo.
--offtopic end--

This. I don't think I'm the only one wanting to be bleeding-edge and it's just silly to have to fetch stuff from unofficial repos because of all these forks. Hardly anyone knows which one will compile, which one will run, which one is Linux/OS X compatible (since these are usually given less priority), etc. Even the AUR contains outdated versions.

Honestly it doesn't bother me much. If you want to use a system before it is officially released then you need to do the work to make sure all of the parts are correct. If everything was in a single place and working then it would be the official release. Having things in separate repos allows people to make changes for one specific thing (like making it OSX compatible, or Linux compatible, or whatever) and then when they have that aspect working, they can merge it back into the main repo for all to use.

[salithus]

--offtopic below--
That's what I hate git/github for. Before cool-distributed-trendy-git-github people gained write access to a single repo and just working there together. Now they're forking and forking, right now we have at least five more or less active dfhack repose, nobody knows which one to use at a given point in time and when changes going to be merged into the "main" repo.
--offtopic end--

This. I don't think I'm the only one wanting to be bleeding-edge and it's just silly to have to fetch stuff from unofficial repos because of all these forks. Hardly anyone knows which one will compile, which one will run, which one is Linux/OS X compatible (since these are usually given less priority), etc. Even the AUR contains outdated versions.

Honestly it doesn't bother me much. If you want to use a system before it is officially released then you need to do the work to make sure all of the parts are correct. If everything was in a single place and working then it would be the official release. Having things in separate repos allows people to make changes for one specific thing (like making it OSX compatible, or Linux compatible, or whatever) and then when they have that aspect working, they can merge it back into the main repo for all to use.

eh, I still prefer the centralized repo with branching/tagging used liberally. that way you can have tags for official releases, branches for people doing whatever they feel like, and a trunk that will always at least compile (or someone pays dearly) even if it isn't 100% functional. actually had a discussion about this today at work and how we will never ever use git for future projects because of the kind of fragmentation I'm seeing on DF projects.

[mifki]

--offtopic below--
That's what I hate git/github for. Before cool-distributed-trendy-git-github people gained write access to a single repo and just working there together. Now they're forking and forking, right now we have at least five more or less active dfhack repose, nobody knows which one to use at a given point in time and when changes going to be merged into the "main" repo.
--offtopic end--

This. I don't think I'm the only one wanting to be bleeding-edge and it's just silly to have to fetch stuff from unofficial repos because of all these forks. Hardly anyone knows which one will compile, which one will run, which one is Linux/OS X compatible (since these are usually given less priority), etc. Even the AUR contains outdated versions.

Honestly it doesn't bother me much. If you want to use a system before it is officially released then you need to do the work to make sure all of the parts are correct. If everything was in a single place and working then it would be the official release. Having things in separate repos allows people to make changes for one specific thing (like making it OSX compatible, or Linux compatible, or whatever) and then when they have that aspect working, they can merge it back into the main repo for all to use.

eh, I still prefer the centralized repo with branching/tagging used liberally. that way you can have tags for official releases, branches for people doing whatever they feel like, and a trunk that will always at least compile (or someone pays dearly) even if it isn't 100% functional. actually had a discussion about this today at work and how we will never ever use git for future projects because of the kind of fragmentation I'm seeing on DF projects.

Yep. Well, actually even with decentralised VCS you don't have to fork and work in different repos, it's just what github made popular and "standard way of using git".
Also, for example, I was going to add dfhack to my build server to automatically build it for 0.40 as development goes until the official release, but it's just not possible - I can't build and publish 5 repos.

[Nopenope]

Yep.
Also, for example, I was going to add dfhack to my build server to automatically build it for 0.40 as development goes until the official release, but it's just not possible - I can't build and publish 5 repos.

Heh, it's funny since I recently told myself I should be writing a script that automatically updates and builds dfhack until I got stuck with the same issue.

[therahedwig]

Strangely enough, you don't see this problem on big opensource software projects, because they make sure that things get merged back into master, and only do big new features in branches, and merge them as soon as they are sure it won't break the rest of the program.

Edit: Though those guys usually have their own git repo and don't use github, and usually also more organised. I guess I can see what you guys mean.

[Warmist]

Yep.
Also, for example, I was going to add dfhack to my build server to automatically build it for 0.40 as development goes until the official release, but it's just not possible - I can't build and publish 5 repos.

Heh, it's funny since I recently told myself I should be writing a script that automatically updates and builds dfhack until I got stuck with the same issue.

Depends on what you want: bleeding edge- pull _Q and ag develop branches into your own (maybe few other you want) and merge and build. Want something more sane: use DFHack develop branch (usually updated 0.5 times a day). Want stable/releases build DFHack master.
I am doing the first thing (not automatically) and don't really care about most other things other people are doing (or at least until it's stable enough to be in master).

[smjjames]

Yeah um, careful with those experimental builds people. Given how dfhack toys with DF's memory, if some obsolete plugin change the wrong things you're likely to end up with crashes and saves corruption... so only use those for fooling around with a fortress you don't care about much.

Also, some people should educate themselves on what OSX, Windows and Linux are. No excuse, you've got Wikipedia and the intertubes at your disposal.

To be fair, nopenope didn't say which one of his downloads was windows compatible.