log4cpp-related linking error with OOT-packages when GNURadio was built with log4cpp #1045
Comments
|
I think this is just one of many symptoms of GNU Radio's lack of dependency tracking in cmake. On my mac, the problem already starts with the includes. Since ${GNURADIO_RUNTIME_INCLUDE_DIRS} is just another name for <install_prefix>/include, it already fails when looking for log4cpp headers. (On Linux that's often not an issue since the headers are in a standard directory that's likely pulled in by another library. Every module uses boost; so if the headers of boost and log4cpp are in the same directory, it works by chance.) Sticking to the current definition of ${GNURADIO_RUNTIME_INCLUDE_DIRS}, the problem already starts in-tree. To compile GNU Radio on my mac, I had to add log4cpp in every module. The same problem is also apparent for the libraries. I think, ${GNURADIO_ALL_LIBRARY_DIRS} should include the directories of the shared libraries that it uses. Currently, it only includes the directories of libgnuradio-xxx, which leads to the above mentioned problem. Even in-tree, there seems to be lots of confusion on how to deal with shared libraries that are indirectly referenced through other modules. Looking again at log4cpp:
Note for in-tree modules the easiest solution, i.e. to just link against runtime, as gr-analog does, is OK. During compilation cmake sets the rpath (or uses the install name on macOS) and, therefore, finds libraries during compilation. The rpath is, however, stripped during installation, which is why OOT modules might not be able to find the libraries (as shown by the above build logs). To deal with this, we could consider to:
It would be interesting to hear your thoughts on that. |
|
@bastibl I had missed this when you added your thoughtful comments above. I think you're on the right track, but we'd need to figure out how to actually automate generating the above CMake variables. |
|
Hi, Is this resolved? I still face the issue with log4cpp on Mac, where I installed gnuradio using Macport developer version.
Issue: Note: I have this code which worked two years ago[version 3.7 I think]. Is there a temporary workaround for this for immediate use? I have tried the fix in below issue with no success: Thanks |
|
So you are trying to build an OOT module against GNU Radio master? Is the code somewhere online? I don't use MacPorts. Does it compile GNU Radio with log4cpp support? Can you run What libraries do you link your module against? Did you try the fix suggested in this thread? Can you post the linker error after |
Almost, As I understand Macport gnuradio devel version updates every week or so.
Any code works the same, simple module with a block, I have put a simple code on GitHub There is another uploaded tutorial facing the same issue.
Yes Macport has the dependency: Log4cpp is available [There is no compile time issue, just during linking]
otool -L /opt/local/lib/libgnuradio-runtime.dylib
I'm not sure what the fix is? Adding log4cpp dependency? if so, I'm not sure how to do that.
[ 4%] Linking CXX shared library libgnuradio-testinggnuradio.dylib |
built with log4cpp See gnuradio/gnuradio#1045
|
I was able to fix this issue [Carles also has similar changes required]: |
|
Great that it fixes your problem, but think it's a workaround rather than a real solution. Without further support from GNU Radio, the OOT would have to test if GNU Radio was build with log4cpp and (in case) search for the library, make sure that it's the same version, and link against it.
Would be great to hear some thoughts on that. (There is one thing I don't understand (and that's why I asked for all the command outputs): Why fail OOT builds with indirect shared library dependencies on mac (in the scenario libgnuradio-tutorial.dylib -> libgnuradio-runtime -> liblog4cpp.dylib, the log4cpp symbols cannot be resolved, which leads to the above error.) But in-tree works (i.e., libgnuradio-blocks.dylib -> libgnuradio-runtime.dylib -> liblog4cpp.dylib) I know that during build shared objects use special settings for the rpath, for example, but I couldn't find something that impacts how symbols are resolved).) |
|
Just as an aside, for GNU Radio 3.8+ and already on the next branch, logging is always turned on and log4cpp is a mandatory requirement, so this seems strictly a 3.7 issue. |
|
I would say log4cpp is just one example where most problems occur. The suggestions were meant in general. On macOS, for example, I have the impression that 90% of the problems are because users link against the wrong version of a library (like system python vs. homebrew/ports python). |
|
I agree. I'm not familiar with the Mac side of things--@michaelld looks after this--my comment was only an aside that the log4cpp complexity has been removed in 3.8. |
|
The issue is with log4cpp 1.1.2. I'm still debugging. Revert to 1.1.1 if you can & it'll work nice & clean. |
|
Many prior issues on macOS were because of the mixed Python issue as @bastibl points out. We've committed code that addresses that issue. This isn't that issue or even related to it. It's an issue with log4cpp & AppenderMapStorageInitializer. I haven't had time to debug it far enough to have a clue what's going on yet. |
|
OK so the problem is the "static" declaration in the Appender class. The variable isn't used for anything anyway, and it's easy to get rid of: |
|
OK. Fixed here in MacPorts: https://trac.macports.org/changeset/91dd35333bbcbd39eeaabf17ba037eeed20d9304/macports-ports . |
|
@michaelld Thanks for the update! That fixed the issue. |
|
Great that it works, but a bit unfortunate that it works good enough to ignore the general problem with configuring OOTs. I wanted to try the patch on homebrew and installed a fixed version of log4cpp somewhere in my home. While I can point GR to use this version, I don't see how I can point OOTs to that location (if we don't add find(log4cpp) to all OOT modules). Since runtime references log4cpp in its include files, but doesn't add the log4cpp path to So, AFAIS, with this slightly unusual installation, I cannot use (most) OOTs. |
|
@bastibl I agree the more general issue is important to address. Can you open a new issue so we can more properly address it outside this particular one? |
|
It would be good to add the LOG4CPP_INCLUDE_DIRS as @bastibl did in his commit from his above comment, assuming that LOG4CPP is enabled. Might be enabled by default by now I don't recall. |
|
After some searching I think the issue is with gnuradio-runtime/include/logger.h.in:38-43 Let's look at the various possible use cases, for GR and an OOT, assuming that both ENABLE_GR_LOG and HAVE_LOG4CPP are both either enabled or disabled: GR: True, OOT: True -> works GR: False, OOT: False -> works GR: False, OOT: True -> fails GR: True, OOT: False -> fails Result: We need a better way to handle logging in OOTs & checking for when GR provides it & when it's not provided. I'll look into what it'll take to fix this & report back here. |
|
In initial testing, the following works for me, replacing the above code. It's more complicated, but it handles the cases well. YA question is whether we also need to replace to code in the top-level config.in.h for these same macros ... {{{ // did GR enable LOG? // if GR does not provide logging and the current module is requesting // if GR provides logging but the current module is not requesting it, // the other 2 cases work; no need to check them! // handle current status of LOG4CPP // did GR use log4cpp? // if GR does not use log4cpp and the current module is requesting it, // if GR provides for using log4cpp but the current module is not // the other 2 cases work; no need to check them! |
|
And now you know firsthand why all this was ripped out on next for 3.8, with logging always enabled and log4cpp always required. |
|
Yup! Is there a specific branch of next with the log4cpp changes, or is it on master? |
|
It is set that way on the 'next' branch currently. |
|
Yes of course not on master duh. OK, looking at that branch I see what you mean about making log4cpp required. So, yes, then if not already done so we need to fix the GR OOT CMake scripts to always require log4cpp and include it for headers and library automagically, now that 1.1.2 is released. This was not required with log4cpp 1.1.0: the header just declared the API such that an OOT that didn't explicitly use logging didn't require linking to log4cpp. Version 1.1.2 added in a static variable that's instantiated just by including the header, and thus requires the library for linking even if the OOT does not explicitly use logging. |
|
Good catch. I don't think the OOT module in gr-utils has been modified. |
|
My preference would actually be to patch log4cpp to move the static variable to the .cpp file to make it benign again; push the fix upstream. This change would be because it's difficult to know when a header might indirectly include log4cpp. The fix I mention would work for GR & should be compatible with most GR OOT modules. But it probably won't work with all of them & certainly not with non-GR projects. My opinion: bad log4cpp for adding in that static variable in the header. |
|
Of course, it's ideal if upstream will fix things. And yes, a pox on anyone that puts things in header files that either allocates storage or forces linkage. |
|
I think moving the static variable from the header to the .cpp code will do the trick. It does allow GNU Radio to execute again, which is a plus. I'm really not sure the intent of placing that static variable in the header; seems like there need be just 1 of them for the code to work correctly. Whatever. The commit is here: macports/macports-ports@03e977a . I'll also create a ticket on the log4cpp SF area & link in that commit and this issue. Fun times! |
|
@michaelld Do we know if this issue has been fixed? I just ran into this using log4cpp 1.1.1 and the latest gnuradio on centos 7. Would downgrading gnuradio help me get through this? This is my cmake command, everything ran ok: The error I ran into while running Also, it says I unassigned jmcorgan just now, not sure how that happened, but apologies nonetheless. |
|
I'm using stock Can you do |
|
I am on centos 7 and the latest version offered from the repo is 1.1.1. If it would work to compile from source 1.1.3 I can try that. Here's the make command on verbose |
|
If it is helpful, here's the output from |
|
Ok so the issue is that there is no "log4cpp" linkage here. Are you trying to build the latest GR GIT master HEAD? Maybe do "git pull" just to verify ... If you are, then we need to go back to the "cmake" command & see what it thinks. |
|
I'm cloning with this command Here's the cmake output. The |
|
@michaelld I installed log4cplus, which is on version 1.1.3 hoping that it would work. I ran the cmake command with the same paths for the log4cpp flags, but when I run make, it errors out saying that there is no such file as log4cpp/Category.hh, which is true, since it's log4cplus instead of log4cpp. With all of this, the log4cpp version on other distros is 1.1.3. Should I try to build that from source and see how it goes? Otherwise, centos 7 is using 1.1.1. |
|
So I was actually able to get past the linking error for log4cpp by doing what is described here, in that you add However, it ran into another error with log4cpp: With the references to log4cpp, I'm assuming that what I did with the cmake command didn't quite fix the issue... |
|
OK so adding the |
|
Thanks, I sent you an email. Edit: |
|
Can we reopen this? I am getting the same error as desribed here. Cmake is finding log4cpp, but when I try and make gnuradio, I get another error. I tried the latest suggests with cmake, but still am getting the same errors. #40 302.2 [ 29%] Linking CXX executable zeromq_swig_gr_zeromq_swig_ed811 CMake |
|
Can you do make VERBOSE=ON and report back the link command that's generating this error? I'm guessing the issue is that Log4CPP is installed outside the CMAKE_INSTALL_PREFIX and thus we need to provide CMake with some library linkage info. |
|
@mwk088 can you please open a new issue for this, recreated your entry, provide the info I ask for, and tag me on it? We'll take this up there. This issue is old enough it's really not clear whether it's the same as yours. |
|
I may have gotten around the issue by installing the newest version of log4cpp for CentOS 8….it is yet to be determined because of my other linking errors with thrift. I will open a new ticket if the issue persists.
From: Michael Dickens <notifications@github.com>
Reply-To: gnuradio/gnuradio <reply@reply.github.com>
Date: Wednesday, December 4, 2019 at 10:27 AM
To: gnuradio/gnuradio <gnuradio@noreply.github.com>
Cc: Mark Koenig <mark.koenig@iubelttechnologies.com>, Mention <mention@noreply.github.com>
Subject: Re: [gnuradio/gnuradio] log4cpp-related linking error with OOT-packages when GNURadio was built with log4cpp (#1045)
@mwk088<https://github.com/mwk088> can you please open a new issue for this, recreated your entry, provide the info I ask for, and tag me on it? We'll take this up there. This issue is old enough it's really not clear whether it's the same as yours.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1045?email_source=notifications&email_token=ANFEJUDKFABLWEDYTISN3PDQW7D5LA5CNFSM4CRQJOH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5MU3Q#issuecomment-561695342>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFEJUEDNVBGSHP3OHW7RQTQW7D5LANCNFSM4CRQJOHQ>.
|
I've just built GNURadio 3.7.10.1 with log4cpp support but now gr-osmosdr fails to compile because of "undefined reference to log4cpp:Appender..." errors since it does not have the information to also link against log4cpp.
Here's the full buildlog from gr-osmosdr:
https://blackhole.pmtu.de/.dump/gr-osmosdr-buildlog-fail.txt
I actually worked around by adding log4cpp to the linker flags manually but it still does not feel like the proper way to address this problem...
https://blackhole.pmtu.de/.dump/gr-osmosdr-fix-log4cpp-linking-error.diff
Conditionally adding the lib4cpp linking flags to gnuradio-runtime.pc could be a solution.
GNUradio was build in a clean chroot-environment.
CMake automatically detected log4cpp and set ENABLE_GR_LOG to ON.
Here's a the GNURadio buildlog:
https://blackhole.pmtu.de/.dump/gnuradio-buildlog-log4cpp.txt
libgnuradio-runtime.so is linked to liblog4cpp.so and so should all programs that make use of this library ...
https://blackhole.pmtu.de/.dump/ldd_libgnuradio-runtime_so.txt
The text was updated successfully, but these errors were encountered: