Build error: error: no matching function for call to 'FreeListAllocator<char>::FreeListAllocator()'
#488
Closed
1 of 3 tasks
Comments
|
This seems related to #440. I was never able to replicate it, but from your output it looks like your gcc is configured to use the old COW string rather than the C++11 conforming string. My understanding is that the old COW string doesn't work with stateful allocators, and will fail to compile with stateful allocators that don't have a default constructor. It should be possible to use the jsoncons library with the old COW strings but without stateful allocators, though. For the second issue, could you confirm for me what is the maximum value of |
|
@danielaparker Thank you for responding! I am pretty sure we do not configure GCC specifically to achieve such a result, but Macports will pass P. S. I will check numeric limits once I am back to some PowerPC machine and update on that. |
|
@barracuda156 My understanding is that |
|
@danielaparker I had an impression that both ABI are functionally identical, just syntax differs. Is it not the case in reality? P. S. While I never tested that, but presumably it could be possible to use the new ABI on any old systems, including PowerPC ones, but everything will have to be rebuilt with the C++11-capable GCC against the new libstdc++ (not the system one). I think this shall work, the only issue is that I won’t be able to push such radical change into Macports. (It may also break some stuff like Qt4.) |
|
There are definitely issues with cow strings, I'll quote from a ycombinator post, "In the early days of std::string multi-threading was much rarer, so reference counting was cheaper. As CPU count grows the relative cost of needing an atomic refcount on every string also grew. The COW strings also were a constant source of surprising behavior. As with any COW object you have to make sure that the copy happens before the write. Simple enough, but the STL-style interface does not support this well. All you had to do is call operator[] or begin() on a non-const std::string and it would force a copy. This meant that something that to the programmer clearly looked like a read-only operation like: ...could end up copying the string. Worse, it also meant that any previously taken references are now invalidated. This lead to horrible bugs where you would hold a pointer at the previous copy of the string (which you no longer own a refcount on) and it would almost always work... but every so often another thread would come by and reuse the memory behind your back. Of course there are also issues with not maintaining backwards compatibility with existing code compiled under the old ABI :-) |
@danielaparker Does this look reasonable? |
|
I removed tests which were broken, and the remaining ones seem to pass, though there is a Is this anything meaningful? ) |
|
This is the patch for now: (At the moment the aim was merely to see what builds and what is the tests output, if it builds at all.) |
12 tasks
|
My conclusion from the original build output is that the main issue has to do with your using a I believe the files that you've removed from the build all contain stateful allocator tests. I think you could achieve the same result, without losing as much test coverage, by adding I've modified the configuration on branch main so that you can compile with I'd like more information about the I need to address the 32 bit warnings. I think the main issue is with binary formats that support 64 bit byte lengths. We need to throw or assert if a binary header contains a length that won't fit into a 32 bit integer. |
Thank you! Will try that.
Could we somehow get per-test-case output in the log?
That would be awesome. |
|
@danielaparker I am away from my PowerPC hardware for about a week more, so there is a bit of delay with testing. I return to this issue as soon as I am back. If you could find time to address 32-bit warnings, please let me know. |
|
@barracuda156 The 32-bit warning that you reported earlier has been addressed on master. If you find any others, please report them, thanks. |
|
@danielaparker Thank you! I will return to this in a couple of days then. |
|
@danielaparker Building from 08b1b4f I still get 32-bit-caused errors: To be clear, I dropped all my patches and only pass |
|
Could you check again with the latest code on master? Thanks. |
|
Oh sorry, the latest will still fail, this is a "comparison is always true due to limited range of data type" warning rather than a 32 bit issue per se. It would compile if I commented out the last if condition, but I don't think that's right. |
|
@danielaparker What will be an appropriate solution here? |
|
Either use a pragma to selectively deactivate the warning in that does not trigger the warning. I notice that another cbor project that compiles on many environments uses I've changed it to that on master, you can try that. |
|
Building from 8088c81 still fails, but on |
|
Oh, good. We'll try the same strategy for msgpack. |
|
When you get a chance, can you check master again? |
Sure, thanks! (In the mid of 12 hrs rebuild of gcc and libgcc now, so perhaps update on this tomorrow.) |
|
@danielaparker Running the build now, will update on result. |
|
Failed on this: Build attempted from 9368ac6 |
|
Should be fixed on master |
|
Apparently not yet, from f67f926 it still fails: |
|
@danielaparker So should this be fixed now? I will test it then. |
|
I think there's still a (innocuous) uninitialized warning in this one environment. I haven't seen it in any other. May need to suppress it. |
|
@barracuda156 , could you have another go at testing the code on master? Thanks! |
|
@danielaparker Sure, gonna try today. |
|
Using 640c0e4 does not work still: Looks like the same No patches applied, only passing |
|
Passing -DJSONCONS_HAS_STATEFUL_ALLOCATOR=0 is no longer necessary. I've been reading up on |
|
Actually, hold off on testing again, there's a few more things I can check. |
|
@danielaparker Has this already been addressed? 0.176.0 fails here: Also, I had to pass |
|
@danielaparker This is the only failure, provided BTW, isn't some C++17 standard needed here? I see nothing passed on the command line. Maybe that is why things break down? |
|
The polymorphic allocator tests will only be compiled if
We test with C++11, C++14, C++17 and C++20 compilers. |
|
@danielaparker Yes, I have seen that, and gcc13 certainly supports C++17. What I mean is that However I get the error with that file, and only there ( |
|
No idea. It may compile if you explicitly set |
|
Although if I were guessing based on your compiler output, I'd guess that your compiler/standard library might be supporting the pmr namespace and polymorphic allocators, but not the alias |
Obviously, disabling is an easy fix, but I wanted to figure out why that case fails specifically. I will try your suggestion. |
|
A quick search suggests that it's related to your _GLIBCXX_USE_CXX11_ABI setting. |
|
@danielaparker Ok, then perhaps if replacement does not work, we have to add a patch to skip that test with gcc builds. |
|
@barracuda156 , If by any chance you're still tracking this issue, could you test one more time? Thanks. |
|
master, that is. |
|
@barracuda156 Yeah, I will do it by tomorrow. |
|
Sorry, still fails: This is from 800736a with no patches and |
|
You need |
|
@danielaparker Okay, now it worked (with both flags passed). |
Thanks! I will be happy to close this issue in the next release. |
|
Thank you! |
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Build fails with GCC:
Enumerate the steps to reproduce the bug
sudo port -v build jsonconsWhat compiler, architecture, and operating system?
What jsoncons library version?
P. S. There is another error, but it is due to -Werror being the default, i.e. avoidable. Looks like due to bitness:
The text was updated successfully, but these errors were encountered: