configure: error: You have a broken version of the <tr1/unordered_set> header
Hi everybody,
I did a bzr checkout and tried to compile a more recent version of inkscape - both: X11 and aqua.
In both procedures the following configure error occured:
configure: error: You have a broken version of the <tr1/ unordered_set> header. See http://wiki.inkscape.org/wiki/index.php/ CompilingMacOsX for information on how to fix this problem.
The wiki page says I shall get a
Working version of the <tr1/unordered_set> and <tr1/unordered_map> headers
but doesnt say how I can get one. Could someone tell me?
BTW.: What I noticed is that the osx-build.sh script still contains some code on svn. This may not be relevant in this context - but might be worth to be fixed occasionally. Shall I file it as a bug?
Yours, Wolf
On Feb 22, 2010, at 12:20 AM, Wolf Drechsel wrote:
Hi everybody,
I did a bzr checkout and tried to compile a more recent version of inkscape - both: X11 and aqua.
In both procedures the following configure error occured:
configure: error: You have a broken version of the <tr1/unordered_set> header. See http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX for information on how to fix this problem.
The wiki page says I shall get a
Working version of the <tr1/unordered_set> and <tr1/unordered_map> headers
but doesnt say how I can get one. Could someone tell me?
BTW.: What I noticed is that the osx-build.sh script still contains some code on svn. This may not be relevant in this context - but might be worth to be fixed occasionally. Shall I file it as a bug?
Yours, Wolf
Yes, please file one.
I think it is fairly important to try to keep things working by default in the trunk. That's one of our main overall goals.
I would think that on such platforms (OS + compiler) where tr1/unordered_set is not stable, we really should use a config variable to use a different map. That proposed "fix" on the wiki really appears to be a work-around.
That's basically one of the main reasons to use Autoconf or such so that we do build properly on multiple platforms.
2010/2/22 Jon Cruz <jon@...18...>:
I would think that on such platforms (OS + compiler) where tr1/unordered_set is not stable, we really should use a config variable to use a different map. That proposed "fix" on the wiki really appears to be a work-around.
I'd rather have an URL in the configure error message that points to the wiki page with instructions. Otherwise we'll be stuck with the fix for a long time. The fix will be ugly and will require either a) extra boilerplate whenever a hash set is used or b) including a copy of the correct header in the tarball.
Regards, Krzysztof
On Feb 22, 2010, at 3:37 PM, Krzysztof Kosiński wrote:
I'd rather have an URL in the configure error message that points to the wiki page with instructions. Otherwise we'll be stuck with the fix for a long time. The fix will be ugly and will require either a) extra boilerplate whenever a hash set is used or b) including a copy of the correct header in the tarball.
No, that's not really true. First is that there are more than two options.
More important is that we should only use an optimized data structure when required. This includes measuring performance before and after the switch.
But the *KEY* is that forcing an end user to patch their system is FAR UGLIER!!!
I'll see what I can do with helping the encapsulation to minimize the problem and your perceived ugliness..
2010/2/22 Jon Cruz <jon@...18...>:
That proposed "fix" on the wiki really appears to be a work-around.
I do not agree with your definition of "fix" and "workaround". For me: Fix: something that removes the issue. Workaround: something that doesn't fix the issue but allows the program to function correctly.
Given those definitions, adding ifdefs to use some different hash implementation is a workaround, while the user replacing his broken header with a working one is a fix.
More important is that we should only use an optimized data structure when required.
What is the difference between a normal data structure and "optimized" data structure? In my book, the standard hash set and hash map are normal data structures. Are you suggesting we should use structures that do not correctly represent the semantics of data (e.g. storing set elements in a vector) because it is somehow simpler, or that using the correct structure is premature optimization?
More important is that we should only use an optimized data structure when required. This includes measuring performance before and after the switch.
I replied to this before. I don't need any justification for using the theoretically optimal structure, but you do need benchmark data to demonstrate that some other theoretically suboptimal structure is better in practice.
But the *KEY* is that forcing an end user to patch their system is FAR UGLIER!!!
If the system is obviously broken, I don't see how it's ugly for the user to fix it. Apple's toolchain is not a sacred cow. Fixing the bug at its source is trivial (overwrite 1 file), and somebody who succeeded installing all the required Macports libraries that are required to build Inkscape will be perfectly capable of doing it. Please do not introduce useless cruft to fix a bug that is already fixed where it should be (GCC).
Regards, Krzysztof
On 2/23/2010 11:48 AM, Krzysztof Kosiński wrote:
2010/2/22 Jon Cruz <jon@...18...>:
That proposed "fix" on the wiki really appears to be a work-around.
I do not agree with your definition of "fix" and "workaround". For me: Fix: something that removes the issue. Workaround: something that doesn't fix the issue but allows the program to function correctly.
Given those definitions, adding ifdefs to use some different hash implementation is a workaround, while the user replacing his broken header with a working one is a fix.
I think the exact opposite could be argued using your definitions too. Your proposed fix only works around the issue for a single user on a single machine but the problem remains for the next user. Jon's work around fixes the issue for everyone without requiring any more work on their part. This seems rather consistent with the intent of autoconf and other such tools: detect the capabilities of the platform and build properly. That's just one hugely well established work around.
More important is that we should only use an optimized data structure when required.
What is the difference between a normal data structure and "optimized" data structure? In my book, the standard hash set and hash map are normal data structures. Are you suggesting we should use structures that do not correctly represent the semantics of data (e.g. storing set elements in a vector) because it is somehow simpler, or that using the correct structure is premature optimization?
More important is that we should only use an optimized data structure when required. This includes measuring performance before and after the switch.
I replied to this before. I don't need any justification for using the theoretically optimal structure, but you do need benchmark data to demonstrate that some other theoretically suboptimal structure is better in practice.
Perhaps Jon is arguing that it is good to justify any _change_ with a benchmark. That seems reasonable to me. Use a benchmark to confirm that the theoretical optimality matches up well against your real world workload. Show that you have correctly understood the issue and that the expected gains have materialized.
Aaron Spike
That proposed "fix" on the wiki really appears to be a work-around.
I do not agree with your definition of "fix" and "workaround". For me: Fix: something that removes the issue.
More important is that we should only use an optimized data structure when required.
Hello friends,
I happened to have a gcc43 on my machine and tried - using the same setting which created the error - to compile an aqua version. Produced a load of warnings, but went through and left me back with a working inkscape. - I'll do another test with the X11 version, when the ncursesw problem is fixed.
As far as I understood the whole thing, the basic problem is a bug in Apple's gcc4.0.1. Wouldn't it be the smartest fix to switch over to a more recent compiler - which may bare some more advantages (such as improved AltiVec and multiprocessor support)?
I do have a macports gcc43 and a gcc44 now on my G4/Tiger - which took many hours to compile… If somebody would push my nose onto a dummy proof set of instructions, I'd be happy to make .pkgs of both and provide them - and we could get rid of outdated 4.0.1.
One step further could be to make a package of Apple's command line developer tools (and what else is required from the Xcode tools), provide that separately and get independent from Xcode tools - most of which is not required for inkscape anyways.
Yours, Wolf
On Feb 24, 2010, at 12:13 AM, Wolf Drechsel wrote:
As far as I understood the whole thing, the basic problem is a bug in Apple's gcc4.0.1. Wouldn't it be the smartest fix to switch over to a more recent compiler - which may bare some more advantages (such as improved AltiVec and multiprocessor support)?
Well, that was more of the immediate symptom, not the real problem.
The basic problem is that a developer changed code to use some feature that is not supported on all target platforms. This is actually a common occurrence, and there are many standard tools and approaches for this. That is much of what autotools provides for us. Inkscape has been successfully handling such cases for years.
Autoconf will check for each library, tool, feature and bug that might be pertinent, then configures things to compensate for that. Thus it simplifies the problem to one that allows a single source distribution of a piece of software to be built successfully on a large range of targets.
Even better in this case is that we're not the only one who has seen this issue. First we have autoconf just detect/test and then set HAVE_HASH_SET, HAVE_UNORDERED_SET, or HAVE_TR1_UNORDERED_SET. Then
#if defined(HAVE_TR1_UNORDERED_SET) #include <tr1/unordered_set> #elif defined(HAVE_UNORDERED_SET) #include <unordered_set> #elif defined(HAVE_HASH_SET) #include <ext/hash_set> #endif
Of course, to avoid needing boilerplate everywhere a solution usually tosses those into a single .h file that is included instead of <tr1/unordered_set>, etc. Add a dash of typedef magic and you now have robust source code that is actually portable.
On Feb 23, 2010, at 9:48 AM, Krzysztof Kosiński wrote:
2010/2/22 Jon Cruz <jon@...18...>:
That proposed "fix" on the wiki really appears to be a work-around.
I do not agree with your definition of "fix" and "workaround". For me: Fix: something that removes the issue. Workaround: something that doesn't fix the issue but allows the program to function correctly.
Given those definitions, adding ifdefs to use some different hash implementation is a workaround, while the user replacing his broken header with a working one is a fix.
Just look through the existing config code in Inkscape.
Making our software build on many platforms is a goal and a realizable target. Telling all end users to just upgrade to the latest and greatest generally is not.
*If* the user has updated things, then we can fix it. But if not, it is fairly trivial to correct the code.
More important is that we should only use an optimized data structure when required.
What is the difference between a normal data structure and "optimized" data structure? In my book, the standard hash set and hash map are normal data structures.
Not in any of the books I have.
"set" is the base type. "hash set" or "unordered set" are specializations that are optimized for certain uses.
Are you suggesting we should use structures that do not correctly represent the semantics of data (e.g. storing set elements in a vector) because it is somehow simpler, or that using the correct structure is premature optimization?
That is not the most important thing.
In software engineering it has generally been accepted (through experience, quantified studies, etc.) that simple is better. Occam's razor is the preferred tool of the experienced professional.
Oh, and far better than optimizing the code is just optimizing the algorithms. Not "How can I do this faster" but "how can I not do this so we will be faster". The areas you are using this in are actually such areas, and we do have some HUGE potential for end-user improvement. That is more where I would like to be able to focus attention, due in part to the usability we can gain. If you can take a bit of time and lay out why this data structure is better, when it helps, when it doesn't, and some rough numbers on things then I think we can do some amazing work. A simple wiki page to gather it would be good.
I'd like to be doubly clear on this point. You have been working on some very low-level things, and have gotten some nice performance re-gains. However there are a few big-picture things that can be done to change approach and gain an order of magnitude in performance. I'd like to help pin those down so you can move on to those big win items.
More important is that we should only use an optimized data structure when required. This includes measuring performance before and after the switch.
I replied to this before. I don't need any justification for using the theoretically optimal structure, but you do need benchmark data to demonstrate that some other theoretically suboptimal structure is better in practice.
Well, then you just prove that you are not a software engineer.
We *need* to do the right thing. If the "theoretically optimal" structure is better in practice, then a five minute test is all it would take. However, every single book I have ever seen on software engineering stresses to actually test these theoretical issues. Start with simple, and *then* tune up those areas that benefit in the real world from it. And if such changes are not that complex, then testing them is not either.
But the *KEY* is that forcing an end user to patch their system is FAR UGLIER!!!
If the system is obviously broken, I don't see how it's ugly for the user to fix it.
Just ask anyone who has every dealt with customer support, either as a first-line person, as a support engineer, or as a software engineer trying to debug a customer issue. This is a real big ugly.
Apple's toolchain is not a sacred cow. Fixing the bug at its source is trivial (overwrite 1 file), and somebody who succeeded installing all the required Macports libraries that are required to build Inkscape will be perfectly capable of doing it.
I'm not saying Apple's toolchain is a sacred cow. Not at all.
What I am saying is that Inkscape can and *has* taken the choice of trying to work for as many people as possible. Given a single engineer taking a single afternoon and changing things in one place versus having hundreds of non-engineer end users changing their local systems in ways that can and do break things (C++ is notorious for version issues, but at least we're not on Qt where it is worse) the proper choice *should* be clear.
Please do not introduce useless cruft to fix a bug that is already fixed where it should be (GCC).
Again, this is not useless cruft. It is a *GOAL* of the Inkscape project to be cross-platform and portable. This includes NOT REQUIRING END USERS TO GO TO THE LATEST UPDATES OF EACH AND EVERY COMPONENT. Yes, we do want to draw the line at some point, but keeping things portable is one key to maintaining a low barrier to entry. Keeping a low barrier to entry is one key thing that keeps our project growing and progressing.
You keep having issues with this. If it were not an ongoing issue, I'd not make such a big deal. But again, just because "it works for me, Krzysztof" does not mean it works for everyone.
Oh, and keep in mind... the template you want to use is not standard. That was the problem early on, and that is a problem now. It is not part of the stl that is required. Now in newest versions of gcc it is usually present, but that is not always the case. Keeping our codebase flexible to the point of not requiring the use of an optional component is helpful for those using other than gcc. Of course I wouldn't suggest people use MSVC instead, but there are some nice high-end compilers that some end users have been using for Inkscape. And among other things that means that minimizing the patching they have to do on their end is just being a good citizen.
I think this discussion has grown much longer and hairier than it deserves.
Since, as I understand, it only affects compiling and only on OSX, I think I'm siding with Krzysztof. Regular OSX users don't compile things, and those who compile Inkscape for them can do the workaround until the Apple compiler is fixed.
Just my uninformed opinon.
On Feb 24, 2010, at 7:20 AM, bulia byak wrote:
I think this discussion has grown much longer and hairier than it deserves.
Since, as I understand, it only affects compiling and only on OSX, I think I'm siding with Krzysztof. Regular OSX users don't compile things, and those who compile Inkscape for them can do the workaround until the Apple compiler is fixed.
Just my uninformed opinon.
Well, we know it happens on OSX, but not that it doesn't on other platforms. Give than other projects have addressed this with simple auto-foo checks, it seems reasonable that we can too. BTW, such checks and fixes showed up on the first page of Google results when I checked briefly.
I'm still fixing other conf issues, but can look at that once I'm done tracking down libpng & libgc detection failure.
What would help even more, though, would be if you could convince Krzysztof to drop in to our chat room occasionally. There are many things that could help resolve.
I fixed this by using Boost unordered containers. Now it should work on all platforms without any fixes. (I have no idea why it didn't work the first time I tried it.)
Regards, Krzysztof
On Mar 2, 2010, at 2:54 PM, Krzysztof Kosiński wrote:
I fixed this by using Boost unordered containers. Now it should work on all platforms without any fixes. (I have no idea why it didn't work the first time I tried it.)
Uh oh. Something seems broken on Ubuntu 9.10:
In file included from desktop.cpp:96: ui/tool/control-point-selection.h:17:35: error: boost/unordered_set.hpp: No such file or directory ui/tool/control-point-selection.h:18:35: error: boost/unordered_map.hpp: No such file or directory
Do you think you can review that config info I pointed out a bit back? It would be very good if our source could still build fine on the most recently released Ubuntu.
Thanks.
On Tue, 2010-03-02 at 23:49 -0800, Jon Cruz wrote:
On Mar 2, 2010, at 2:54 PM, Krzysztof Kosiński wrote:
I fixed this by using Boost unordered containers. Now it should work on all platforms without any fixes. (I have no idea why it didn't work the first time I tried it.)
Uh oh. Something seems broken on Ubuntu 9.10:
In file included from desktop.cpp:96: ui/tool/control-point-selection.h:17:35: error: boost/unordered_set.hpp: No such file or directory ui/tool/control-point-selection.h:18:35: error: boost/unordered_map.hpp: No such file or directory
Works on 10.04... however, I build a TON of stuff on my system (and obviously have a newer build environment). Either way, I would expect autotools to detect if this was not available and to complain appropriately.
Cheers, Josh
On Mar 3, 2010, at 12:14 AM, Joshua A. Andler wrote:
On Tue, 2010-03-02 at 23:49 -0800, Jon Cruz wrote:
On Mar 2, 2010, at 2:54 PM, Krzysztof Kosiński wrote:
I fixed this by using Boost unordered containers. Now it should work on all platforms without any fixes. (I have no idea why it didn't work the first time I tried it.)
Uh oh. Something seems broken on Ubuntu 9.10:
In file included from desktop.cpp:96: ui/tool/control-point-selection.h:17:35: error: boost/unordered_set.hpp: No such file or directory ui/tool/control-point-selection.h:18:35: error: boost/unordered_map.hpp: No such file or directory
Works on 10.04... however, I build a TON of stuff on my system (and obviously have a newer build environment). Either way, I would expect autotools to detect if this was not available and to complain appropriately.
Yes... of course 10.04 isn't even released yet. It's very possible that there is some existing package for 9.04 that would do it for me, but I don't know which. *If* the dependency is properly listed in autotools, then it would at the least tell me what to install to get unblocked.
If help is needed on that front, just let me know. As I mentioned before, I did spot some auto stuff other projects did to deal with this type/issue.
On Mar 3, 2010, at 7:26 AM, Jon Cruz wrote:
Yes... of course 10.04 isn't even released yet. It's very possible that there is some existing package for 9.04 that would do it for me, but I don't know which. *If* the dependency is properly listed in autotools, then it would at the least tell me what to install to get unblocked.
If help is needed on that front, just let me know. As I mentioned before, I did spot some auto stuff other projects did to deal with this type/issue.
I did some quick checking. With the current Ubuntu LTS (Hardy) the included version of Boost is 1.34. That's a release that's still supported for over a year on the desktop, so we probably need to keep working with that at a minimum.
Or maybe we're lucky and the tr1 stuff is just in a different package.
Jon, you "fixed" the problem by adding a lot of ugly defines... I *really* wanted to avoid this. You should have just reverted my commit. http://doc.bazaar.canonical.com/current/en/user-guide/adv_merging.html#rever...
I see that unordered containers are only available since Boost 1.36 - I initially thought they were available for a longer time. In that case, the previous solution (tell Apple users to fix their compiler) looks the best.
Alternatively, we can tell people to install some newer Boost if they want to compile Inkscape - it has no runtime dependencies.
Regards, Krzysztof
On Mar 4, 2010, at 6:35 AM, Krzysztof Kosiński wrote:
Jon, you "fixed" the problem by adding a lot of ugly defines... I *really* wanted to avoid this. You should have just reverted my commit. http://doc.bazaar.canonical.com/current/en/user-guide/adv_merging.html#rever...
Well... yes a revert would have possibly unblocked the immediate build issues...
... but in the long run it is far better to fix the source to work on all platforms rather than fix the platforms to work with the source.
The only real ugly defines in play are those where the custom hash functions are implemented. We probably should revisit those at some point anyway since I'm *extremely* interested in the hash balancing and performance of using pointers as hash values.
*Please* keep in mind that Inkscape uses autotools for a reason. Take a look at the existing configure.ac and some of the checks that it runs. Also check the output and logs. Keeping things easier to build for new users is a *KEY* tenant of the project. We need to keep that low barrier to entry.
Oh, and to illustrate, I *did* try to update my OS X build environment to newer components, but that failed and left me with a broken toolchain (via macports). That's one of the things about the mac platform. Each and every user has a good toolchain included with the OS when they get it, but trying to move to anything beyond the stock does get a bit risky.
W dniu 4 marca 2010 18:54 użytkownik Jon Cruz <jon@...18...> napisał:
Oh, and to illustrate, I *did* try to update my OS X build environment to newer components, but that failed and left me with a broken toolchain (via macports). That's one of the things about the mac platform. Each and every user has a good toolchain included with the OS when they get it, but trying to move to anything beyond the stock does get a bit risky.
Well, the point is that the stock OSX toolchain is not good at all, it's broken.
I can live with the fix, but I cleaned it up slightly by moving the pointer hash definition into the compatibility header, and using all-uppercase for macros.
I added a different implementation of pointer hashing taken from Boost - it uses x + (x >> 3) rather than x directly.
Regards, Krzysztof
On Mar 4, 2010, at 4:33 PM, Krzysztof Kosiński wrote:
Well, the point is that the stock OSX toolchain is not good at all, it's broken.
I can live with the fix, but I cleaned it up slightly by moving the pointer hash definition into the compatibility header, and using all-uppercase for macros.
Thanks. The template cleanup especially is nice.
First question, which platforms use "# include <unordered>"? I see you removed that check outright. It had been in there because other projects included those.
I added a different implementation of pointer hashing taken from Boost
- it uses x + (x >> 3) rather than x directly.
So what are the performance differences you're seeing with that?
I was going to do some testing myself, but I'm not sure which things I should do to exercise it, and what numbers, data, etc. I should use to get some good idea. Do you think you can toss some rough test points (operations, upper and lower limits, etc) up on the wiki so we can address things well? Thanks.
W dniu 5 marca 2010 05:02 użytkownik Jon Cruz <jon@...18...> napisał:
First question, which platforms use "# include <unordered>"? I see you removed that check outright. It had been in there because other projects included those.
AFAIK <unordered_set> / <unordered_map> is the C++0x spelling. The other existing options (in particular TR1 and Boost) should cover compiling in C++0x mode as well.
I added a different implementation of pointer hashing taken from Boost
- it uses x + (x >> 3) rather than x directly.
So what are the performance differences you're seeing with that?
This will lead to less collisions. Most memory is aligned, so the lower 2 or 3 bits of pointers are usually zero - this hash fixes that. I did not benchmark this but I guess we can trust the Boost implementors.
Regards, Krzysztof
On Mar 5, 2010, at 11:57 AM, Krzysztof Kosiński wrote:
This will lead to less collisions. Most memory is aligned, so the lower 2 or 3 bits of pointers are usually zero - this hash fixes that. I did not benchmark this but I guess we can trust the Boost implementors.
Well, we can trust the boost implementors to match certain aspects for certain needs.
The key is to carefully measure usage in a live situation. Even the Boost developers have told me this. We do seem to have a situation with all sorts of interesting factors, and that might be quite informative to actually look at.
participants (6)
-
Aaron Spike -
bulia byak -
Jon Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
Wolf Drechsel