Ada

ada@lists.fedoraproject.org

38 discussions

Updating the Ada packaging guidelines
by Björn Persson 21 Aug '24

21 Aug '24

For any interested parties' awareness: I'm proposing some updates to the Ada packaging guidelines. See the merge request: https://pagure.io/packaging-committee/pull-request/1387 Björn Persson

1 0

Ada in EPEL
by Björn Persson 05 Jun '23

05 Jun '23

For anyone interested in programming in Ada on long-term stable operating systems: I have bootstrapped GPRbuild for EPEL 9. It's now available in the epel-testing repository, along with a few libraries: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-80cb740420 It seemed like there would be no more Ada in RHEL or its derivatives when Red Hat removed Ada support from GCC in RHEL 8 – but a heroic volunteer has made the gcc-epel package that adds back Ada, D, Go, Objective C and Objective C++, and has so far been building updates now and then. Building on that, I'm now working to add GPRbuild and some Ada libraries. For EPEL 9 I built GPRbuild 23. I don't think there will be regular version upgrades in EPEL, but there was no reason to choose an older version when adding a new package. The version of Libgnat in EPEL 8 is too old for GPRbuild 23. I hope to be able to build an older version of GPRbuild for EPEL 8. More libraries will follow if and when I get to them, if I can solve the problems that crop up. Björn Persson

1 0

Hi!
by Kristoffer Grundström 22 Feb '23

22 Feb '23

My name's Kristoffer and I'm not really a user of Fedora per se, but I do however port Fedora packages to Mageia and the time of writing this I'm porting ghc, but there a slight problem building it. Is there a ordered list to build the dependencies? I have ported SOME ghc-related packages already, but now I'm seeing some that uses BuildRequires that are built by ghc itself so I'd be happy if I could get any help with what dependencies to focus at. Alex, Happy, HsColour should be the main focus if I'm not mistaken. Correct me if I'm wrong. I do know how to use urpmq --whatrequires, but it would be better to have a numbered list instead. /Kristoffer

2 1

Updating gprbuild
by Jonathan Steffan 22 Feb '23

22 Feb '23

Hello, An IRC user in #fedora on Libera was asking why gprbuild was out of date and I attempted updating. Worked through the spec in a rawhide mock build and contributed an update to this bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=2171998 Please let me know what I missed and if I could help more. I am not familiar with this software and don't know if disabling these patches is the right thing to do. There is more cleanup that is needed in the spec and I tried to keep everything commented out that was changed. Thanks for any guidance, -- Jonathan Steffan jonathansteffan(a)gmail.com

2 1

Gnatcoll 2018
by Björn Persson 12 Jun '19

12 Jun '19

Gnatcoll 2017 can no longer be built in Fedora 30 because of API changes in libgpr. An upgrade to Gnatcoll 2018 is necessary, but has the complication that Gnatcoll has been split into three separate libraries. I think the best way forward is to make three new source packages – gnatcoll-core, gnatcoll-bindings and gnatcoll-db – and turn the current gnatcoll package into a metapackage that pulls in the three new ones to make upgrades smooth. After a few releases I think we can retire the metapackage. As a start I have a gnatcoll-core review request here: https://bugzilla.redhat.com/show_bug.cgi?id=1685226 I'm not yet sure about the directory layout. I may find that I need to move some files when I make the other packages. Björn

3 6

armv7hl
by Pavel Zhukov 02 Mar '19

02 Mar '19

Hi Ada-lovers, I'm trying to rebuild ada packages with gcc and seems like this time armv7hl is broken. Initially it was a problem with gprinstall code which was crashing on exit from exception handler (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89493) After spending ~1 week on debugging we gave up and I have worked this around by getting rid of Name_Error but now matreshka is failed with segmentation fault, I'm going to drop armv7hl from the list of gprbuild_arches untill bug is fixed because it can take years. -- Pavel Zhukov ШRC: landgraf

2 1

x86 and gnat
by Pavel Zhukov 07 Feb '18

07 Feb '18

Hi Ada coders and lovers, As x86 (32-bit for i686->) is not primary architecture anymore [2] and we have at least one bug which blocks gprbuild [1] (and as the result almost whole stack) I start to think about dropping i686 from the list of GNAT_arches since F26 onward. Any ideas/objections? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1444614 [2] https://fedoraproject.org/wiki/Architectures -- Pavel

2 4

GPS is around the corner
by Pavel Zhukov 01 Aug '17

01 Aug '17

Hi Bjorn ( and other Ada and Fedora lovers :-) ) , Finally I've sorted out job related issues and can dedicate more time on Fedora packaging activities. I have drafts of gnat_util and ASIS packages ready but don't see usecases for them so far. As you know the main missed part is Gnat Programming Studio and users want it! I'm working on it right know but metfew issues there I'd like to discuss (seek for help/advice). Main issues: GPS requires gnatcoll with libgpr support enabled. libgpr is provided by gprbuild and I've managed to build it [1]. However I'm not 100% sure if we can ship additional directories like %{_includedir}/gpr and %{_libdir}/gpr in addition to %{}/gprbuild. I've not found such kind of restriction in Packaging Guidelines through. Do gprbuild-libgpr and gprbuild-libgpr-devel sound good? Gnatcoll itself... As you can see there're two versions of the package on libre.adacore.com. First one is "normal" one which is released with gnat and called gnatcoll-gpl-%{version} and we have it in Fedora for a while. Second one is "special" version for GPS and called gnatcoll-gps. The reason of having this is release time of GPS and Gnatcoll development model. So I can imaging few possible solutions: 1) Use gnatcoll-gps sources in gnatcoll RPM. Disadvantage is having approx. 5 months "older" codebase which was not actually "released". But who cares :) 2) Add second SOURCE to the rpm and gnatcoll-gps subpackage which provides BR for GPS and single gnatcoll-gps.so library to link with. Requires patching of build system and I don't like this part. But advantage is to have gnatcoll which was actually released in distribution. So should be more stable in theory (sigh). 3) Ship gnatcoll-gps sources in gps-gnatcoll-* rpms as BR and runtime libraries. Has same disadvantages as (2) and even more as I don't like the idea to ship gnatcoll in gps package... 4) Do not package gps at all :) Minor issue is GtkAda3 bug [2]. [1] https://copr.fedorainfracloud.org/coprs/landgraf/ada-testing-repo/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1442661 Thank you for ideas/suggestions in advance and have a nice weekend! -- Pavel

3 10

ربات پیام رسان
by majidpor58＠gmail.com 09 Jun '17

09 Jun '17

ربات پیام رسان

1 0

Cuda-8.0 works fine with fesora 25 and CLANG (Experiment)
by ataya＠t-online.de 31 Jan '17

31 Jan '17

The default compiler from Fedora 25 (gcc and g++ Version 6.3 will never work properly with cuda-8.0, even if you change /usr/local/cuda-8.0/include/host_config.h. BUT CLANG do work if you cheat the makefiles. Warning!!! : The nvidia-cuda-developers do know, why they use clang only on apple machines. My way to force cuda using clang on Linux is just an experiment, which worked for me. Use my method only on your own risk. I was able to get Fedora 25 working very fine with cuda-8.0. Steps: 1. Install clang 2. install cuda-8.0 and Nvidia-Driver from nvidia.com 3. sudo gedit /usr/local/cuda-8.0/include/host_config.h and change "6" to "7" in those lines# # if __GNUC__ > 6 #error -- unsupported GNU version! gcc versions later than 6 are not supported! #endif /* __GNUC__ > 6 */ 3. Change the environment variables: 3-a with sudo gedit write this one of those lines /usr/local/cuda-8.0/lib64 (for x86_64-arch) or /usr/local/cuda-8.0/lib (for i386, i686) save the file to: /etc/ld.so.conf.d/nvcuda.conf then do : sudo ldconfig 3-b with sudo gedit write those lines export LDFLAGS=-L/usr/local/cuda-8.0/lib64 (or /usr/local/cuda-8.0/lib) save the file to /etc/profile.d/nvcuda.sh the do: sudo chmod +x /etc/profile.d/nvcuda.sh restart the terminal (Konsole) 4. Force the Makefile in your source code to use clang instead of gcc and g++ in one of those ways (or both): Method 1 : Edit the Makefile in your source code and change the lines with "Host compiler=gcc (or g++) to Hostcompiler=clang or clang++. Method 2: Force the system to use clang instead of gcc and g++: - Medthod 2-a: remove/backup your gcc and g++ compilers with: sudo mv /usr/bin/gcc /home?/user?/gcc-backup sudo mv /usr/bin/g++ /home?/user?/g++-backup sudo mv /usr/bin/x86_64-redhat-linux-g++ /home?/usr?/x86_64-redhat-linux-g++-backup sudo mv /usr/bin/x86_64-redhat-linux-gcc /home?/usr?/x86_64-redhat-linux-gcc-backup - Medthod 2-b: cheat by linking sudo ln -sf /usr/bin/clang /usr/bin/gcc sudo ln -sf /usr/bin/clang /usr/bin/g++ *** Now you can compile CUDA-programs. If you want your gcc and g++ back, just inverse the mentioned mv command removing the -backup suffix Common problem if installing the nvidia-driver from nvidia.com is: the **GL-, and **EGL symlinks in /usr/lib64 will always be re-linkend, if yum updates any GL or EGL-Libraries. That is the reason, why some EGL-programs and GL-Programs will crash. Because of this you may need to relink the symlinks /usr/lib64/libGL.so** and /usr/lib64/libEGL.so to the EGL- and GL-Libraries from Nvidia ( somthing like: sudo ln -sf /usr/lib64/libEGL_nvidia.so.375.26 /usr/lib64/libEGL.so)

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Ada