Closed gombosg closed 4 years ago
Hi, it's really nice to hear... read that :)
Here are the all dependencies needed just in case
Making progress.
What are these? Are the .h
files actually for libantilib
? Is this a library that's going to be shared (linked to by other apps), or something exclusively for this app?
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/include/antimicroX/aboutdialog.h
/usr/include/antimicroX/addeditautoprofiledialog.h
/usr/include/antimicroX/advancebuttondialog.h
/usr/include/antimicroX/advancebuttondialoghelper.h
/usr/include/antimicroX/advancestickassignmentdialog.h
/usr/include/antimicroX/antimicrosettings.h
/usr/include/antimicroX/antkeymapper.h
/usr/include/antimicroX/applaunchhelper.h
/usr/include/antimicroX/autoprofileinfo.h
/usr/include/antimicroX/autoprofilewatcher.h
/usr/include/antimicroX/axiseditdialog.h
/usr/include/antimicroX/axisvaluebox.h
/usr/include/antimicroX/baseeventhandler.h
/usr/include/antimicroX/buttoneditdialog.h
/usr/include/antimicroX/buttoneditdialoghelper.h
/usr/include/antimicroX/calibration.h
/usr/include/antimicroX/capturedwindowinfodialog.h
/usr/include/antimicroX/commandlineutility.h
/usr/include/antimicroX/dpadcontextmenu.h
/usr/include/antimicroX/dpadcontextmenuhelper.h
/usr/include/antimicroX/dpadeditdialog.h
/usr/include/antimicroX/dpadeditdialoghelper.h
/usr/include/antimicroX/dpadpushbutton.h
/usr/include/antimicroX/dpadpushbuttongroup.h
/usr/include/antimicroX/editalldefaultautoprofiledialog.h
/usr/include/antimicroX/eventhandlerfactory.h
/usr/include/antimicroX/extraprofilesettingsdialog.h
/usr/include/antimicroX/flashbuttonwidget.h
/usr/include/antimicroX/gamecontroller.h
/usr/include/antimicroX/gamecontrollerdpad.h
/usr/include/antimicroX/gamecontrollerdpadxml.h
/usr/include/antimicroX/gamecontrollerexample.h
/usr/include/antimicroX/gamecontrollermappingdialog.h
/usr/include/antimicroX/gamecontrollermappingdialoghelper.h
/usr/include/antimicroX/gamecontrollerset.h
/usr/include/antimicroX/gamecontrollertrigger.h
/usr/include/antimicroX/gamecontrollertriggerbutton.h
/usr/include/antimicroX/gamecontrollertriggerxml.h
/usr/include/antimicroX/gamecontrollerxml.h
/usr/include/antimicroX/globalvariables.h
/usr/include/antimicroX/inputdaemon.h
/usr/include/antimicroX/inputdevice.h
/usr/include/antimicroX/inputdevicebitarraystatus.h
/usr/include/antimicroX/inputdevicexml.h
/usr/include/antimicroX/joyaxis.h
/usr/include/antimicroX/joyaxisbutton.h
/usr/include/antimicroX/joyaxiscontextmenu.h
/usr/include/antimicroX/joyaxiscontextmenuhelper.h
/usr/include/antimicroX/joyaxiswidget.h
/usr/include/antimicroX/joyaxisxml.h
/usr/include/antimicroX/joybutton.h
/usr/include/antimicroX/joybuttoncontextmenu.h
/usr/include/antimicroX/joybuttonmousehelper.h
/usr/include/antimicroX/joybuttonslot.h
/usr/include/antimicroX/joybuttonslotxml.h
/usr/include/antimicroX/joybuttonstatusbox.h
/usr/include/antimicroX/joybuttonwidget.h
/usr/include/antimicroX/joybuttonxml.h
/usr/include/antimicroX/joycontrolstick.h
/usr/include/antimicroX/joycontrolstickbutton.h
/usr/include/antimicroX/joycontrolstickbuttonpushbutton.h
/usr/include/antimicroX/joycontrolstickcontextmenu.h
/usr/include/antimicroX/joycontrolstickcontextmenuhelper.h
/usr/include/antimicroX/joycontrolstickeditdialog.h
/usr/include/antimicroX/joycontrolstickeditdialoghelper.h
/usr/include/antimicroX/joycontrolstickmodifierbutton.h
/usr/include/antimicroX/joycontrolstickpushbutton.h
/usr/include/antimicroX/joycontrolstickstatusbox.h
/usr/include/antimicroX/joydpad.h
/usr/include/antimicroX/joydpadbutton.h
/usr/include/antimicroX/joydpadbuttonwidget.h
/usr/include/antimicroX/joydpadxml.h
/usr/include/antimicroX/joygradientbutton.h
/usr/include/antimicroX/joystick.h
/usr/include/antimicroX/joystickstatuswindow.h
/usr/include/antimicroX/joytabwidget.h
/usr/include/antimicroX/joytabwidgetcontainer.h
/usr/include/antimicroX/joytabwidgethelper.h
/usr/include/antimicroX/localantimicroserver.h
/usr/include/antimicroX/logger.h
/usr/include/antimicroX/mainsettingsdialog.h
/usr/include/antimicroX/mainwindow.h
/usr/include/antimicroX/messagehandler.h
/usr/include/antimicroX/mouseaxissettingsdialog.h
/usr/include/antimicroX/mouseaxissettingsdialoghelper.h
/usr/include/antimicroX/mousebuttonsettingsdialog.h
/usr/include/antimicroX/mousebuttonsettingsdialoghelper.h
/usr/include/antimicroX/mousecontrolsticksettingsdialog.h
/usr/include/antimicroX/mousecontrolsticksettingsdialoghelper.h
/usr/include/antimicroX/mousedpadsettingsdialog.h
/usr/include/antimicroX/mousedpadsettingsdialoghelper.h
/usr/include/antimicroX/mousehelper.h
/usr/include/antimicroX/mousesettingsdialog.h
/usr/include/antimicroX/qkeydisplaydialog.h
/usr/include/antimicroX/qtkeymapperbase.h
/usr/include/antimicroX/qtuinputkeymapper.h
/usr/include/antimicroX/qtx11keymapper.h
/usr/include/antimicroX/quicksetdialog.h
/usr/include/antimicroX/sdleventreader.h
/usr/include/antimicroX/setaxisthrottledialog.h
/usr/include/antimicroX/setjoystick.h
/usr/include/antimicroX/setjoystickxml.h
/usr/include/antimicroX/setnamesdialog.h
/usr/include/antimicroX/simplekeygrabberbutton.h
/usr/include/antimicroX/slotitemlistwidget.h
/usr/include/antimicroX/springmoderegionpreview.h
/usr/include/antimicroX/stickpushbuttongroup.h
/usr/include/antimicroX/uinputeventhandler.h
/usr/include/antimicroX/uinputhelper.h
/usr/include/antimicroX/unixcapturewindowutility.h
/usr/include/antimicroX/vdpad.h
/usr/include/antimicroX/virtualkeyboardmousewidget.h
/usr/include/antimicroX/virtualkeypushbutton.h
/usr/include/antimicroX/virtualmousepushbutton.h
/usr/include/antimicroX/x11extras.h
/usr/include/antimicroX/xmlconfigmigration.h
/usr/include/antimicroX/xmlconfigreader.h
/usr/include/antimicroX/xmlconfigwriter.h
/usr/include/antimicroX/xtesteventhandler.h
/usr/lib/debug/usr/lib64/libantilib.so-2.25-1.fc32.x86_64.debug
/usr/lib64/libantilib.so
Yes, this idea was modelled on my own experience when I was writing my thesis. The application linked to other full programs as to additional functionalities in menu. But the fact is, it was written in Haskell, which focuses very much on modularity, so attaching other programs resembled combining lego bricks. If antimicrox was to be part of something bigger someday, it could be used as a library. But if it doesn't make sense in the end, then I will withdraw it.
Thanks, it's okay, I just needed to know this for packaging. :slightly_smiling_face:
Here's the submission: https://bugzilla.redhat.com/show_bug.cgi?id=1844850
It fails to build on armv7hl
architecture, one of the supported arches for Fedora (like Raspberry Pi and other mini computers).
Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=45515901 Log: https://kojipkgs.fedoraproject.org//work/tasks/5914/45515914/build.log
Here's a working x86_64
build log: https://kojipkgs.fedoraproject.org//work/tasks/5916/45515916/build.log
If you want to diff them.
It fails while linking libantilib.so
.
Can this be fixed, or should I file for an ExcludeArch
? As I see it's the last build step so I hope there's some fix.
The actual error part:
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerdpad.cpp.o:(.rodata+0x0): multiple definition of `typeinfo name for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x28): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerdpad.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0x0): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerdpad.cpp.o:(.rodata+0x18): multiple definition of `typeinfo name for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x40): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerdpad.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0xc): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerset.cpp.o:(.rodata+0x0): multiple definition of `typeinfo name for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x28): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerset.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0x0): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerset.cpp.o:(.rodata+0x18): multiple definition of `typeinfo name for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x40): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/gamecontrollerset.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0xc): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/xml/gamecontrollerdpadxml.cpp.o:(.rodata+0x0): multiple definition of `typeinfo name for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x28): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/xml/gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0x0): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/xml/gamecontrollerdpadxml.cpp.o:(.rodata+0x18): multiple definition of `typeinfo name for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x40): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/gamecontroller/xml/gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0xc): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/xml/setjoystickxml.cpp.o:(.rodata+0x0): multiple definition of `typeinfo name for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x28): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/xml/setjoystickxml.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for JoyDPadXml<JoyDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0x0): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/xml/setjoystickxml.cpp.o:(.rodata+0x18): multiple definition of `typeinfo name for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.rodata+0x40): first defined here
/usr/bin/ld: CMakeFiles/antilib.dir/src/xml/setjoystickxml.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for JoyDPadXml<VDPad>'; CMakeFiles/antilib.dir/src/gamecontroller/xml/moc_gamecontrollerdpadxml.cpp.o:(.data.rel.ro+0xc): first defined here
make[2]: *** [CMakeFiles/antilib.dir/build.make:4318: libantilib.so] Error 1
Similar to #111 . Working on it, but he skipped this kind of problem installing newer version of gcc
It looks like common problem with the architecture: Link, the problem here is with template class, just like in my case. Libantilib itself probably has nothing to do with it. So try to do something with ExcludeArch
Thanks for the link. I can't help because I have no clue about C++ programming and I don't have an armv7
computer (ok, I could do in a VM, and if you push any commit to some branch I can checkout and make Fedora Koji scratch builds at any time to check).
In the conversation you have linked, codeblocks
was fixed from the upstream side.
RHBZ
Codeblocks ticket - same error message
Commit that fixed it if that helps.
Ok, I will try it
Nice, I'll make a Fedora scratch build today later.
I did a build on master
but get this:
Installed (but unpackaged) file(s) found:
/usr/share/antimicroX/Changelog
But there's also /usr/share/doc/antimicroX/Changelog
which is identical and is the correct place for the Changelog
IMO. Is /usr/share/antimicroX/Changelog
supposed to be there?
I did a scratch build anyway, and it still fails on armv7hl
only :cry: with the same as before. log
So I'll exclude that arch for now.
yes, for resource files to be detected but can be in doc too
I've tagged the program
Awesome! Hopefully it'll be reviewed soon or I'll go for a review swap.
Hi, I finally received some review feedback, and these issues could be fixed upstream. Please provide some feedback about these.
/usr/share/doc/antimicroX/Changelog
/usr/share/doc/antimicroX/README.md
/usr/share/licenses/antimicroX/LICENSE
(So that I don't have to in the specfile :slightly_smiling_face:, it's just good packaging/repository hygiene.)
libantilib
is supposed to have some soname versioning, or otherwise moved from the default ld path (/usr/lib64
) into e.g. some subdirectory. You could maybe patch this to add versioning or help me out if there is some compiler command line flag to tell where it should be placed, so that the app would still start.As far as I know, appropriate operations of this type can be performed in spec, PKGBUILD and similar files. The distributions are different and one of the ways is just to put the appropriate rules in the compilation file, which put the required libraries in the required places.
@sirlucjan Yes and no. Of course I can easily remove an executable permission. 🙂
But unversioned .so
files are generally a bad practice in ld conf paths - for good reason -, and adding versioning to them is simple if you know what you're doing and also good for the project in the long run.
In this case, Fedora packagers are supposed to inform upstream and work with them to resolve the situation:
In cases where upstream ships unversioned .so library (so this is not needed for plugins, drivers, etc.), the packager MUST try to convince upstream to start versioning it. [...] Under no circumstances should the unversioned library be shipped in Fedora.
Unfortunately, I don't know much about building packages, so that's why I asked for either a patch to add versioning, or some build flag to use, because such thing not detailed in BuildOptions.md
.
Here's an example when I asked upstream of adding versioning to a library with cmake. It's not a big change and it's better to get this into upstream than creating a downstream patch in a specfile.
@juliagoda what do you think?
Thank you. I should have told you I was doing the same thing, but I had an "interesting" day yesterday, so I didn't find the time. Now I'm working on choosing the path for the antilib, it works, but it doesn't link correctly yet and the application can't see it. I will check your change and take it
Super! Note that my PR keeps antilib
in the original /usr/lib64
path, just adds a version to it. It's up to you to choose between adding versioning or moving it. (Or doing nothing, in which case I'll add #124 as a downstream specfile patch.)
To use this you must write something like this (where .. is from subdirectory like build for example):
cmake -DANTILIB_PATH="/usr/share/antimicroX/antilib" ..
Package reviewed, built in Rawhide and submitted as an update to F32 and F31. If you want to test and give karma: F32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f022a8b41 F31 https://bodhi.fedoraproject.org/updates/FEDORA-2020-939340c81f
I also set up Release-Monitoring for automatic update notifications: https://release-monitoring.org/project/100902/
Shout out to me if you need anything. Will submit a PR to the README once this gets into the repos (after 7 days at most).
Thanks for going through this with me!
Hi, I'm very happy to see this fork of Antimicro being maintained.
Antimicro has been orphaned in Fedora, but I'll resubmit this as
antimicrox
, it shouldn't be too hard to reconstruct from the original specfile.Also, I'll submit to
alternativeto.net
. :slightly_smiling_face:Keep up the good work!