Recent changes to support-requests

#41 Visual Studio 2010 dll issue

Sanfour — Tue, 20 Jul 2021 12:56:49 -0000

Hi Abhishek,
am using VS 2019 and downloaded it with Nuget package. you need the winsock lib, either you put it by putting ws2_32.lib in Project properties -> Linker-> input -> additional dependys or just add pragma comment(lib,"ws2_32.lib") to your code.

#41 Visual Studio 2010 dll issue

Alexander Perepelkin — Sat, 10 Jul 2021 06:30:49 -0000

Abhishek,

Have you tried it before with earlier versions (like Visual Studio 2010)? I wonder whether it is the change in IDE version which causes the error or the fix above is insufficient.

#41 Visual Studio 2010 dll issue

Abhishek Mishra — Thu, 08 Jul 2021 09:16:41 -0000

Hi Alexander, I am getting the same error on version 1.1.3 (using as a Nuget package). I am using VS2019 for the development. Can you please look into this, and if possible please provide any workaround or fix ? Thanks in advance.

#42 Use of static variable in Appender.hh results in build issues

Michael Dickens — Mon, 12 Jun 2017 01:49:50 -0000

Hi Alexander - I haven't looked into changing the GNU Radio code, but such a change is certainly doable if desired. We've already implemented a workaround by adding "-llog4cpp" to LDFLAGS in its PKGCONFIG file -- which is what's used by CMake as the starting point for determining whether its installed. That said, these changes do not fix the broader issue; they are just workarounds. I would hope you could address the broader issue here ... but, I really don't know what the solution. Cheers! - MLD

#42 Use of static variable in Appender.hh results in build issues

Alexander Perepelkin — Sun, 11 Jun 2017 09:59:47 -0000

Michael,

I glanced a the links you gave and devoted some thoughts to it.
I share your belief; what's not used is better not to be taken. I wonder if that's possible to arrange gnuradio-runtime's API in such a way where in-project usages include API and logging, whether out-of-project usages include API only. In other words, is it possible to separate logging from API there?

Alexander.

#42 Use of static variable in Appender.hh results in build issues

Michael Dickens — Sun, 04 Jun 2017 07:38:38 -0000

Hi Alexander - Thanks for looking into this; no problems on delays.

The code in gnuradio-runtime is found here:
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/logger.h.in
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/logger.cc

Please note that the header is actaully C++ even though its extension is just ".h". The ".in" is used by CMake during configuration to swap out the "#cmakedefine" lines depending on whether the variable was defined or not.

Please also note that the macros ENABLE_GR_LOG and HAVE_LOG4CPP in the above code were fixed about a month ago to allow for more robust logging options for both in-project and out-of-project #include. That said, the next gnuradio-runtime release will require log4cpp & these macros will go away & thus this issue will be relevant.

The issue here is as I wrote originally: If I try to build an out-of-tree module such as "gr-foo", which does not directly use log4cpp but does require gnuradio-runtime's API which #include's log4cpp, then I will have to link gr-foo against log4cpp's library.

My belief is that if a project does not directly use another project, then it should not be required to link against that project's library. The static initializer will be created no matter whether log4cpp is actually being used. If log4cpp isn't being used, then this static initializer should not be required.

Thanks for looking into this issue. I'm happy to discuss further and help in testing and debugging possible fixes. - MLD

#42 Use of static variable in Appender.hh results in build issues

Alexander Perepelkin — Sat, 03 Jun 2017 13:41:57 -0000

Hello Michael,

Sorry for not answering for long time.
The code you referred to follows so called 'nifty counter idiom'. ( https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter )
Intent is shortly described there.
The purpose here is to initialize memory area once for keeping map of all allocated appenders inside. These appenders will be released during program exiting so no memory will be reported as lost.
Moving this initializer into implementation .cpp file effectively meant that only single translation unit (Appender.cpp) would prevent the static initializer (and therefore all the appenders) from being destroyed. If some other client code still counted on using logging abilities then the program would crash on exit due to attempting to write log information into appenders which are already released.
I however consider this as an open question and invite you to discuss that.
Would you give a link to the code which had the trouble you described in this ticket please?

Thanks,
Alexander.

#42 Use of static variable in Appender.hh results in build issues

Alexander Perepelkin — Mon, 08 May 2017 09:58:32 -0000

status: open --> accepted
assigned_to: Alexander Perepelkin
Group: -->

Use of static variable in Appender.hh results in build issues

Michael Dickens — Thu, 04 May 2017 01:40:33 -0000

In Appender.hh:164 is the core

static Appender::AppenderMapStorageInitializer appenderMapStorageInitializer

which is at the top-level log4cpp namespace. This variable will be initialized by any code #include'ing it, whether directly or indirectly. Any direct inclusion is probably OK since the including project is probably linking to log4cpp directly too.

Any indirect inclusion is problematic, since the project is probably not linking to log4cpp directly & will need to do so to link cleanly. GNU Radio has this exact issue with out-of-tree (OOT) modules: A module has to #include from inside GNU Radio's headers, which in turn #include log4cpp headers. The OOT should not need to link to log4cpp, since it's not using the code directly.

A fix is found here: https://github.com/macports/macports-ports/commit/03e977add031301f57ca69729d829c607fe8d316#diff-066b9a66ca6ab453ac31b765b8caed86

It's really not clear what the intent ot this variable is beyond making sure that

_appenderMapStorageInstance

is initialized, and just once. Hence why I think moving the static variable from the header into the .cpp file is the correct fix (as per the MacPorts commit).

Use of static variable in Appender.hh results in build issues

Michael Dickens — Thu, 04 May 2017 01:40:33 -0000

Ticket 42 has been modified: Use of static variable in Appender.hh results in build issues
Edited By: Alexander Perepelkin (sanchouss_)
Status updated: u'open' => u'accepted'
Owner updated: None => u'sanchouss_'