Adam,
Lack of a blcr-dkms package in Zesty likely means that BLCR does not
support kernels as new as used in this distro (unless it has been
renamed?). Unfortunately, that means no BLCR. So, I am surprised that
the other blcr packages are distributed at all.
I am the "upstream" for BLCR, but I
Adam,
Is the blcr-dkms package installed?
That is the ubuntu package containing the kernel modules.
FWIW: blcr-dkms is not listed as dependency for the blcr package because
that would create an unwarranted dependency for multiple MPI packages
which are built with BLCR support but most
Adam,
This error indicates that the kernel modules for BLCR are not loaded.
Unless something has changed recently in the packaging for BLCR, the
kernel modules should be loaded automatically at boot. However, if you
have not rebooted since the install, they might not be.
Is you run
I have been successfully using 1:3.6.2-3ubuntu2 on arm64 since some time
after it appeared in wily-proposed.
I have just now removed and re-installed from the xenial repository to be
certain.
Clang-3.6 is indeed working now.
IMHO, this bug may be closed.
-Paul
--
You received this bug
Public bug reported:
The following Debian bug is present in clang-3.6-1:3.6.2-1 (which is the
current version for arm64/wily)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801695
Note that bug report is closed, indicating that the problem is resolved
in clang-3.6-1:3.6.2-2
** Affects:
There is absolutely no connection between blcr and gnuradio or libboost.
This bug should not be reported against package=blcr.
** Package changed: blcr (Ubuntu) = gnuradio (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
FYI:
A beta release of BLCR 0.8.6 is now in Debian Experimental and should resolve
this bug.
Hopefully once 0.8.6 is out of Beta, the Debian package will move out of
Experimental.
-Paul
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is a known up-steam issue.
BLCR does not yet support 3.8.x and newer kernels.
-Paul (the up-stream maintainer)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1198804
Title:
blcr-dkms 0.8.5-2:
Joni-Pekka,
For those folk that saw this error when upgrading their system, but only
had BLCR's kernel modules installed due to a recommends from another
package, removal of the blcr-dkms package was (and still is) a viable
solution. For those who need a *functional* BLCR, it was initially
What fix: has been released?
As the upsteam maintainer I am not aware of any released support for 3.0 or
later kernels in blcr.
I am actively working on exactly such support and expect a Beta release of
blcr-0.8.5 for testing sometime this week.
The only fix detailed in this bug report is to
Benjamin,
Thanks for the testing.
I don't have any commit access, though as BLCR's upstream I've
committed the patch to our repository for inclusion in the next release.
Hopefully you or Alan Woodland can commit the patch.
-Paul
--
You received this bug notification because you are a member
Ahh... I see the real problem now:
The standard-specified type is siginfo_t, not struct siginfo, though that
has *historically* been correct with glibc and is still the type on the kernel
side of the interface.
I think the include of stddef.h is proper, even if it is not the key issue
here,
The error in comment #5 above is somewhat suspicious.
The symbol CR_ASM_SI_PID_OFFSET is a preprocessor define in the
configure-generated blcr_config.h.
Therefore a small literal integer (such as 12 or 16) should have been expanded
in place of this token, and there should be no symbol left for
The log attached by bdrung contains the following:
checking for value for CR_ASM_SI_PID_OFFSET... not found
for both the 64- and 32-bit library configuration steps.
This explains how the suspicious linker failure is possible (no
#define in blcr_config.h).
This presumably means that there is
Following up on my own comment with an educated guess:
I can see looking at the generated configure script that the compiler
might be seeing multiple #defines for offsetof() when including stdio.h
and stdlib.h as part of the autoconf macro boilerplate. That could
result in a failure to compile
Hello from upstream.
The DKMS log shows
checking kernel symbol table for __put_task_struct... configure: error:
Found symbol __put_task_struct but no declaration -- please file a bug report.
This says the symbol WAS found. So the problem is not a rename, but a
missing or relocated
For the record: I can reproduce w/ the 2.6.31-9-rt kernel in karmic, and I am
pursuing the problem there.
So, one may ignore my request (in the previous comment) for help getting the
Lucid kernel sources.
-Paul
--
package blcr-dkms 0.8.2-9 failed to install/upgrade: blcr kernel module failed
Using the karmic -rt kernel headers I can confirm that this is the only
symbol causing configure-time problems. The one-line patch below is
sufficient to resolve that issue.
However, there are also non-trivial changes in linux/semaphore.h that
break things at compile time and will take some time
OK, that was not as bad as I had feared.
This attachment makes two minor changes to BLCR that are sufficient for
me to manually (e.g. not using DKMS) configure and build for the
linux-2.6.31-9-rt kernel for Karmic/x86_64. These changes are such that
I think it highly unlikely to break any other
The DKMSBuildLog.txt appears to show gcc (or maybe make?) experiencing a
SIGSEGV.
This is not something that changes to the BLCR kernel module are likely to fix.
I suggest that you first ensure that the gcc and make packages are up-
to-date.
-Paul (the primary BLCR developer)
--
package
Alan said Seems odd that it would end up missing those macros.
For the curious:
At about 2.6.26 the type struct mutex was replaced by struct
semaphore, and the various mutex-related functions and macros were
implemented in terms of wrappers around the semaphore code. These
wrappers still exist
pablomme,
I am unsure from your comment if you actually used the blcr kernel modules,
or just loaded them?
If you only loaded them, then I suggest testing them via make insmod check
from the blcr build directory. You should be cautious in case the kernel
crashes (unlikely, but not
pablomme,
Sorry to cause some confusion. I had not considered that the debian/ubuntu
packaging for BLCR splits the kernel modules off into a DKMS package. Because
of that split, the build directory you are using contains no test codes. So,
it would be great if you could build from the
pablomme,
Thanks for the good news!
Now, somebody needs to answer Alan's concern (comment #12) of how we
might get this into the Lucid release: Alan is the Debian maintainer
for the blcr package, but if he commits changes there they may not make
it into Lucid this late, right?
-Paul
--
24 matches
Mail list logo
