Cool!, I would stick with the -Wno-undefined-var-template solution, libstdc++
on the mac is old and it actually prevents you from using any of the new stuff
in c++11, some of which is a huge improvement.
Just for completeness, the Xcode libstdc++ does have <cstdint> but it’s in the
tr1/ directory which, back then, was the “here’s some new stuff that might get
in the standard”. So to get that you need to include <tr1/cstdint>. Like I
said, I would avoid it though.
google will lead any future stumblers to this thread so I shouldn't worry about
it. I’m sure others on this list who are familiar with cmake could add the
flag. Otherwise when someone using gcc upgrades to one of the newer versions
they will be forced to sort out the forward declaration issue.
Cheers,
- James
> On May 17, 2017, at 7:20 PM, paulcrawfordgm <paulcrawfor...@gmail.com> wrote:
>
> Hi James,
>
> Sorry that I seem so naive on these issues but I have not dealt with anything
> on this scale before and I use “C” only, not “C++” for my project.
>
> That being said, I did find the file “CMakeCache.txt” in the pulseview
> directory and I have edited it to add the flag you suggested,
> -stdlib=libstdc++, to both the compiler and linker. That change definitely
> did clear the error I was getting on variable instantiation but it has also
> introduced a new error: “make” cannot find the header file #include <cstdint>
>
> I did google that and it seems that it is a replacement for <stdint.h> but
> there seem to be some things about it that I should probably not be getting
> into just to build pulseview ;-).
>
> I assume that make is looking for <cstdint> because of going back to the old
> gcc from long ago…
>
> Do you think make would work if I put cstdint in my “include” directory. If
> so, where can I get the file? Or should I try the -Wno-undefined-var-template
> flag now that I know where to put it?
>
> In fact, I did try the “-W” flag only (removed the "-stdlib” flag) and it is
> presently happily compiling.
>
> Not only that it actually works!!
>
> <pulseview.png>
>
> Thank you so much for your patience. How do I need to proceed to ensure that
> my experience here gets into some form within sigrok to help others with the
> same software environment as me?
>
> Best regards,
>
> Paul
>
>> On May 17, 2017, at 15:22, James Burgess <jamesrburg...@mac.com
>> <mailto:jamesrburg...@mac.com>> wrote:
>>
>> Hi Paul,
>>
>> The build is made with cmake which generates the Makefiles for you. Are you
>> not running cmake yourself? That’s where you’d add those compile time
>> options, and then in cmake run “generate” again. If you don’t want to edit
>> source code that’s probably your only option. You can edit the makefiles
>> that cmake creates but if you run cmake’s generate it’ll just overwrite them
>> (hence that warning in the file you mentioned)
>>
>> OK, so Xcode8 still defaults to c++03, I know the date of __cplusplus is
>> oddly set to 1997, this is the "build software by large committee effect" in
>> action :-) c++03 was so similar to c++98 they didn’t change it (I guess),
>> and weirdly c++98 was “blessed" in the spring of 1998 but the change of the
>> define’s value was committed in the winter of 1997. Yuk.
>>
>> Don’t think clang will support any lower values, it will however go into a
>> gcc-from-sometime-ago mode with the following flag to the compile and link
>> lines: -stdlib=libstdc++. This selects a completely different c/c++ runtime
>> that was frozen in time when Apple switched to clang (from gcc). As odd as
>> that sounds it’s still a viable runtime on 10.12. It’s been a long time
>> since I compiled sigrok on a mac and I think that would have been when
>> libstdc++ was the default (the default is clang’s own libc++ now) If I can
>> find my notes on that I’ll post them
>>
>> - James
>>
>>
>>> On May 17, 2017, at 11:28 AM, paulcrawfordgm <paulcrawfor...@gmail.com
>>> <mailto:paulcrawfor...@gmail.com>> wrote:
>>>
>>> Hi James,
>>>
>>> Thank you so much for your quick response.
>>>
>>> This is all running on predefined scripts and I am not sure that I have the
>>> ability to move or split headers.
>>>
>>> I looked at the “Makefile” for Pulseview but could not find in it any -W
>>> options that I could add -Wno-undefined-var-template to to change the
>>> compilation behaviour. Perhaps it is somewhere else that I am not looking
>>> at. For my own project compilations it is obvious where to add the options,
>>> but for Pulseview the Makefile is generated automatically and has the
>>> warning not to edit it so the options presumably come from somewhere else.
>>> Perhaps you can enlighten me on that...
>>>
>>> I am using Xcode 8.3.2 and the command line tools for that version.
>>>
>>> When I executed:
>>> sh-3.2# clang++ -dM -c -E -x c++ - </dev/null | grep cplusplus
>>> #define __cplusplus 199711L
>>>
>>> it appears that __cplusplus is already defined to 199711L. I did also use
>>> the -std flag to change that and got the same as you showed:
>>>
>>> sh-3.2# clang++ -dM -c -E -x c++ -std=c++11 - </dev/null | grep cplusplus
>>> #define __cplusplus 201103L
>>>
>>> but when I did “make" again the same error was there. I also found that
>>> using -std=c++03 results in #define __cplusplus 199711L
>>>
>>> What would the -std flag value be to go even lower in dates, or would that
>>> be dangerous for other reasons?
>>>
>>> Thanks again,
>>>
>>> Paul
>>>
>>>
>>>> On May 17, 2017, at 12:55, James Burgess <jamesrburg...@me.com
>>>> <mailto:jamesrburg...@me.com>> wrote:
>>>>
>>>> Hi Paul,
>>>>
>>>> My guess would be that in modern C++ the rules about template definitions
>>>> have been significantly tightened and clang is generally more strict than,
>>>> say, gcc about most of the new rules. The rule in question (I think) is
>>>> that you can no longer define a template whose parameter types are forward
>>>> declared. Previously this was ok as long as you didn’t instantiate the
>>>> template until the parameter types were fully defined.
>>>>
>>>> Sometimes this can be resolved just be including the headers for the
>>>> forward declared type ahead of the template definition (to make it fully
>>>> defined). Sometimes this won’t work if the headers are structured in a way
>>>> to take advantage of the old behavior. An example would be someone has
>>>> used a forward declaration to reduce the header file dependency on some
>>>> type, then it can get tricky. I’ve found I’ve had to split headers to
>>>> resolve those kinds of problems.
>>>>
>>>> The other thing you could try is adding -Wno-undefined-var-template to the
>>>> compile line, most (all?) of the clang options have the negation by adding
>>>> "no-“ in front of them.
>>>>
>>>> Another is, you didn’t say which Xcode you are using, likely 8 given
>>>> you’re on 10.12, the default I think is -std=c++11, you might try
>>>> something lower. Xcode7 defaults to c++03, which you can determine with
>>>> this command (this is Xcode7):
>>>>
>>>> jrb# clang++ -dM -c -E -x c++ - </dev/null | grep cplusplus
>>>> #define __cplusplus 199711L
>>>>
>>>> Here’s how you use the -std flag to change that:
>>>>
>>>> jrb# clang++ -dM -c -E -x c++ -std=c++11 - </dev/null | grep cplusplus
>>>> #define __cplusplus 201103L
>>>>
>>>> (c++03 decided to not change the date to 2003, who knows why ;-)
>>>>
>>>> Hope that helps,
>>>>
>>>> - James
>>>>
>>>>
>>>>
>>>>> On May 17, 2017, at 9:04 AM, paulcrawfordgm <paulcrawfor...@gmail.com
>>>>> <mailto:paulcrawfor...@gmail.com>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am attempting to build Pulseview in MacOS 10.12.5. When I do “$ make” I
>>>>> get an error:
>>>>>
>>>>> [ 2%] Building CXX object CMakeFiles/pulseview.dir/main.cpp.o
>>>>> In file included from /Users/paulcrawford/pulseview/main.cpp:25:
>>>>> /usr/local/Cellar/libsigrok/HEAD-64f628b/include/libsigrokcxx/libsigrokcxx.hpp:969:20:
>>>>> error: instantiation of variable 'sigrok::EnumValue<sigrok::LogLevel,
>>>>> sr_loglevel>::_values' required
>>>>> here, but no definition is available
>>>>> [-Werror,-Wundefined-var-template]
>>>>> const auto pos = _values.find(static_cast<Enum>(id));
>>>>> ^
>>>>> /Users/paulcrawford/pulseview/main.cpp:118:45: note: in instantiation of
>>>>> member function 'sigrok::EnumValue<sigrok::LogLevel, sr_loglevel>::get'
>>>>> requested here
>>>>>
>>>>> context->set_log_level(sigrok::LogLevel::get(loglevel));
>>>>> ^
>>>>> /usr/local/Cellar/libsigrok/HEAD-64f628b/include/libsigrokcxx/libsigrokcxx.hpp:990:57:
>>>>> note: forward declaration of template entity is here
>>>>> static const std::map<const Enum, const Class * const> _values;
>>>>> ^
>>>>> /usr/local/Cellar/libsigrok/HEAD-64f628b/include/libsigrokcxx/libsigrokcxx.hpp:969:20:
>>>>> note: add an explicit instantiation declaration to suppress this warning
>>>>> if
>>>>> 'sigrok::EnumValue<sigrok::LogLevel, sr_loglevel>::_values' is
>>>>> explicitly instantiated in another translation unit
>>>>> const auto pos = _values.find(static_cast<Enum>(id));
>>>>> ^
>>>>> 1 error generated.
>>>>> make[2]: *** [CMakeFiles/pulseview.dir/main.cpp.o] Error 1
>>>>> make[1]: *** [CMakeFiles/pulseview.dir/all] Error 2
>>>>> make: *** [all] Error 2
>>>>>
>>>>> Can anyone advise on how to correct this error.
>>>>>
>>>>> Thanks for any help.
>>>>>
>>>>> Paul Crawford
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>>>> http://sdm.link/slashdot_______________________________________________
>>>>> <http://sdm.link/slashdot_______________________________________________>
>>>>> sigrok-devel mailing list
>>>>> sigrok-devel@lists.sourceforge.net
>>>>> <mailto:sigrok-devel@lists.sourceforge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>>>>> <https://lists.sourceforge.net/lists/listinfo/sigrok-devel>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>> http://sdm.link/slashdot_______________________________________________
>>> <http://sdm.link/slashdot_______________________________________________>
>>> sigrok-devel mailing list
>>> sigrok-devel@lists.sourceforge.net
>>> <mailto:sigrok-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>>> <https://lists.sourceforge.net/lists/listinfo/sigrok-devel>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
