OK. Thanks again!
> On May 17, 2017, at 22:44, James Burgess <jamesrburg...@mac.com> wrote:
>
> 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
>> <mailto: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
