apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'
by Sandro Mani
Hi
I'd need help with the following issue with apitrace, which failed the
mass rebuild with:
apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:70:
undefined reference to `__libc_dlopen_mode'
apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:72:
undefined reference to `__libc_dlsym'
The code triggering this is below. Have these symbols disappeared from
libc resp is there any alternative?
Thanks
Sandro
-----
/*
* Protect against dlsym interception.
*
* We implement the whole API, so we don't need to intercept dlsym --
dlopen is
* enough. However we need to protect against other dynamic libraries
* intercepting dlsym, to prevent infinite recursion,
*
* In particular the Steam Community Overlay exports dlsym. See also
* http://lists.freedesktop.org/archives/apitrace/2013-March/000573.html
*/
PRIVATE
void *
dlsym(void * handle, const char * symbol)
{
/*
* We rely on glibc's internal __libc_dlsym. See also
* http://www.linuxforu.com/2011/08/lets-hook-a-library-function/
*
* Use use it to obtain the true dlsym. We don't use __libc_dlsym
directly
* because it does not support things such as RTLD_NEXT.
*/
typedef void * (*PFN_DLSYM)(void *, const char *);
static PFN_DLSYM dlsym_ptr = NULL;
if (!dlsym_ptr) {
void *libdl_handle = __libc_dlopen_mode("libdl.so.2",
RTLD_LOCAL | RTLD_NOW);
if (libdl_handle) {
dlsym_ptr = (PFN_DLSYM)__libc_dlsym(libdl_handle, "dlsym");
}
if (!dlsym_ptr) {
os::log("apitrace: error: failed to look up real dlsym\n");
return NULL;
}
}
return dlsym_ptr(handle, symbol);
}
2 years, 8 months
Stepping down as Fedora Jam maintainer
by Erich Eickmeyer
Hello all,
A little over a year ago, I came to the Fedora project to revive and
modernize the Fedora Jam project. I have successfully done that. My
vision was that it would be a great way to help develop and test the
most recent advancements in Linux audio.
Unfortunately, or fortunately, life has a way of changing for the good
or the bad. Back in November, I was offered an opportunity that I could
not pass-up: becoming the User Experience Director for the Kubuntu
Focus brand of laptops made by MindShareManagement. Since then, I have
become an integral member of that team, directly reporting to the CTO,
CEO, and President, working directly with the PR and Sales and
Marketing directors. It has been a blast, and is a project that works
directly with Ubuntu and Debian to create, as we put it, the "Ultimate
Linux Laptop". As a MOTU for Ubuntu, this was a perfect fit.
I didn't come here to be a shill for Ubuntu or to advertise my work,
but rather, to illustrate the level of involvement. It has taken up a
majority of my time, and my work with Ubuntu Studio is directly
involved with the project as well as both Ubuntu Studio and the Kubuntu
Focus laptop have similar synergies.
Because of the amount of time involved in these projects, something has
to give. For that reason, I must step-down as Fedora Jam maintainer. My
plan is to continue to maintain certain packages within Fedora (which,
admittedly, I've been slacking on), but I am orphaning the vast
majority of my packages. Here's the list:
Add64
dssi
dssi-vst
fedora-jam-backgrounds*
fedora-jam-kde-theme*
fluidsynth
fluidsynth-dssi
freqtweak
gnome-guitar
harmony-seq
hexter-dssi
jackctlmmc
jmeters
libinstpatch
lv2-c++-tools
lv2-fabla
lv2-ll-plugins
lv2-mdaEPiano
lv2-newtonator
lv2-sorcer
lv2-swh-plugins
lv2-vocoder-plugins
meterbridge
non-daw
portmidi
radium-compressor
realTimeConfigQuickScan
whysynth-dssi
xsynth-dssi
*These packages have pagure repos which I'd be happy to hand over to
whoever takes these.
I do want to thank everyone for the opportunity, including Matthew
Miller, Ben Cotton, Neal Gompa, and many others that helped me revive
this project. I'm sad to let it go, and I'm not sure what's going to
happen to it, but I hope someone who has a passion for the latest
technologies in Linux Audio and music production can take it over.
Thanks,
Erich Eickmeyer
2 years, 8 months
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags. This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.
== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: law(a)redhat.com
== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.
This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file. This should significantly
improve build times for most packages in Fedora.
To ensure that we can identify packages that need the opt-in now and
in the future, the plan is to pass to brp-strip-lto a flag indicating
whether or not the package has opted into -ffat-lto-objects. If
brp-strip-lto finds .o/.a files, but the package has not opted into
-ffat-lto-objects, then brp-strip-lto would signal an error.
== Benefit to Fedora ==
The key benefit to Fedora is improved package build times and lower
load on the builders.
== Scope ==
* Proposal owners: The feature owner (Jeff Law) will need to settle on
a suitable RPM macro to indicate an opt-in to -ffat-lto-objects,
implement the necessary tests in brp-strip-lto and opt-in the initial
set of packages. This will be accomplished by doing the prototype
implementation locally, building all the Fedora packages to generate
the opt-in set. Committing the necessary opt-ins, then committing the
necessary changes to the RPM macros.
* Other developers: There should be minimal work for other
developers. The most likely scenarios where other developers will
need to get involved would include:
# Packages which are excluded from x86_64 builds and which need the
opt-in will need the appropriate package owners to add the opt-in.
# Packages which are FTBFS when the builds are run to find the set of
packages that need to opt-in and which need to opt-in will need
packager attention.
# It is possible that the faster builds may trigger build failures in
packages that have missing dependencies in their Makefiles. We saw a
few of these during the initial LTO work and those packages were
either fixed or -j parallelism removed. This work may expose more of
these problems.
I expect these all to be relatively rare occurences, but with 9000+
packages in Fedora I wouldn't be surprised if we see a few of each of
these issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed) This
should have no release engineering impacts.
* Policies and guidelines: The packaging guidelines will need to be
updated to document the new macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This proposal does not align with any
current Fedora Objectives.
== Upgrade/compatibility impact ==
This change should have zero impact on upgrade/compatibility. In
fact, the change should have no user visible impacts.
== How To Test ==
No special testing is needed. Any issues with this proposal will show
up as FTBFS issues.
== User Experience ==
Users should see no changes to the user experience.
== Dependencies ==
Packages which need to opt-in to -ffat-lto-objects will need their
.spec files updated to include the
new macro.
== Contingency Plan ==
If this can not be completed by final development freeze, then the RPM
macro changes would not be installed and the change could defer to
Fedora 35.
* Contingency mechanism: Proposal owner will only commit the RPM macro
changes once the opt-in package set has been identified and opt-ins
added to those package's spec files. So no special contingency
mechanism should be needed
* Contingency deadline: It is most beneficial to have this completed
before the mass rebuild; however, the drop dead date should be beta
freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
No upstream documentation. Packaging guidelines will need a minor update.
== Release Notes ==
I do not expect this change to require any release notes.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months
Free Pascal and F35 Mass Rebuild
by Mattia Verga
Hello folks,
I've just noticed that in F35 Mass rebuild everything related to Free
Pascal is now failing to build.
The fpc compiler itself is FTB with the following output:
/usr/bin/ld:
/builddir/build/BUILD/fpcbuild-3.2.2/fpcsrc/rtl/units/powerpc64-linux/si_c.o:(.data.n_TC_$SI_C_$$_START_ADDRESSES+0x10):
undefined reference to `__libc_csu_init'
/usr/bin/ld:
/builddir/build/BUILD/fpcbuild-3.2.2/fpcsrc/rtl/units/powerpc64-linux/si_c.o:(.data.n_TC_$SI_C_$$_START_ADDRESSES+0x18):
undefined reference to `__libc_csu_fini'
Error: Error while linking
From a quick search on search engines it seems a glibc misconfiguration
of some sort... ?
The latest fpc that was built successfully on F35 used glibc
2.33.9000-2.fc35
I've not yet opened a ticket on BZ for that, I'm waiting for the
automatic FTB ticket. I just wanted to raise attention on this.
Mattia
2 years, 8 months
HEADS UP: OpenEXR 3.X coming soon!
by Richard Shaw
So I've spent about 40 hours pushing through build problems in the COPR[1]
I've set up beating what packages I could into submission and moving the
ones I couldn't (or shouldn't) port to the openexr2 compat package.
Some of the ones I didn't even try porting were packages that looked to be
legacy like the kde3/kde4 ones or packages on their 40th release with no
activity upstream. I don't want to update any package when it's unlikely or
impossible (dead upstream) that OpenEXR 3 will ever be supported officially.
Some packages only needed some build system updates because of the
restructuring of the libraries. Others needed just a little bit of porting
in the code.
With all that said, I'm down to one package/problem... Blender
The problem is not with Blender itself, but rather that it depends on
OpenVDB and I've already confirmed with upstream that OpenEXR 3 will not be
supported until the next major release. Ironically they are both under the
stewardship of the Academy Software Foundation (AWSF) so great coordination
there... :/
That being said, OpenSceneGraph wasn't ready either but it was relatively
easy to port after I figured out that the EXR plugin it builds doesn't
create a fatal error during the build when it fails (frustrating!)
Ok, and as usual, writing all of this has helped me work through porting
OpenVDB... I'll see about sending the patch upstream.
I'll probably create the side-tag tomorrow and start working on the builds.
Thanks,
Richard
2 years, 8 months
Macro to smoke-test-import a Python module in %check
by Miro Hrončok
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that
can help to test-import a Python module in %check when no other tests exist or
are when they cannot be executed during build [1].
The semantics is quite simple:
%check
%py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at
lest one fails to import, the entire build fails. The above line is translated
very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the
implementation [0] for more accurate representation). Given the Python
semantics, it is possible to use commas as module separators as well (but no
parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to
be manually BuildRequired or even better, generated in %generate_buildrequires
via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is
undesired (e.g. when only one module can be imported from the same Python
interpreter):
%check
%py3_check_import mymodule.either
%py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name?
- Do you have better ideas for the macro semantics?
[0]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 8 months
Flagged projects in Anitya
by Richard Fearn
Hi,
Does anyone know who looks after flagged projects in Anitya? I've
flagged a couple of projects for deletion, but so far nothing has
happened.
Regards,
Richard
--
Richard Fearn
richardfearn(a)gmail.com
2 years, 8 months
Problem with Python 3.10 and python-wxpython4 in Rawhide
by Steven A. Falco
I have python3-wxpython4 4.0.7-19.fc35 and python3 3.10.0~b4-3.fc35 on a rawhide VM. I get the following error:
rawhide$ python -c "import wx;print(wx.version())"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib64/python3.10/site-packages/wx/__init__.py", line 17, in <module>
from wx.core import *
File "/usr/lib64/python3.10/site-packages/wx/core.py", line 12, in <module>
from ._core import *
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 261: invalid continuation byte
free(): invalid size
Aborted (core dumped)
Should I file a bug on Fedora, or should it go upstream, and if so, where?
Thanks,
Steve
2 years, 8 months
