-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPL 2018 asserts during relocatable library building #45
Comments
by the way, the code entered on Feb 22: |
Most likely yes. Can you tell us what value are you getting there in your case? |
I don't know the value. I assumed it was just undefined based on the assert. I can't run this in gdb so I don't know how to provide any more information. |
this code is in gprbuild-link.adb:
So I'm guessing For_Project.Config.Run_Path_Origin needs to be checked that it's not "No_Name". The question I have is what lines need to be skipped if it is. Has @lambourg had a chance to look at this? I'm loathe to roll back gprbuild to 2017 again. I'd like to go forward. |
This might be solution:
When I first put it before the Get_Name_String (For_Project.Config.Run_Path_Origin)) line, I got another failure involving an undefined access later. This patch allows gprlib to build. I'll report back if it seems allow gprbuild to function correctly. |
gprbuild isn't working quite right, and I don't know if it's because the patch above isn't right, or for some other reason. What I'm see is that if -lgnat or -lgnarl are added the flags, gprbuild is not add rpaths to the adalib directories. I think this used to happen with gprbuild 2017. For what it's worth, the following alternate patch doesn't change the behavior either.
Can someone confirm that the adalib directory is supposed to be added to the rpath automatically when -lgnarl or -lgnat flags are needed? That'll confirm that my build of gpl 2018 is malfunctioning. |
anyone? |
Hello, $ cd Test28
$ gprbuild -P tools/tools.gpr
Setup
[mkdir] object directory for project Gnoga
[mkdir] library directory for project Gnoga
[mkdir] library directory for project Gnoga_Agg
[mkdir] exec directory for project Tools
tools.gpr:4:09: warning: there are no sources of language "Ada" in this project
gnoga.gpr:5:17: source file "gnoga-application.linux" for unit "gnoga.application.open_command" not found
gnoga.gpr:5:17: warning: there are no sources of language "Ada" in this project
gprbuild: "tools/tools.gpr" processing failed
$ cd ..
$ gprbuild -P test28/tools/tools.gpr
gprbuild: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : gpr-names.adb:225
Load address: 0x1079dd000
Call stack traceback locations:
0x107ed5041 0x107c8444b 0x107b8f445 0x107b95eb6 0x107b97253 0x107b97bb1 0x1079ec932 0x107f005a1 GPRBuild is ok when it is invoked in the base folder but not ok when it is invoked in a another folder as the parent folder in my test case. |
FWIW, this isn't GPL-2018 specific. I see the same assert on the public development branches, i.e. gcc version 9.0.1 20190227 and xmlada/gprbuild from github (master) running on Ubuntu Bionic LTS. Repeating your test and providing stack trace with symbols. steve@bionic:\~/Desktop$ cd test28
steve@bionic:\~/Desktop/test28$ gprbuild -P tools/tools.gpr
tools.gpr:4:09: warning: there are no sources of language "Ada" in this project
gnoga.gpr:5:17: source file "gnoga-application.linux" for unit "gnoga.application.open_command" not found
gnoga.gpr:5:17: warning: there are no sources of language "Ada" in this project
gprbuild: "tools/tools.gpr" processing failed
steve@bionic:\~/Desktop/test28$ cd ..
steve@bionic:\~/Desktop$ gprbuild test28/tools/tools.gpr
gprbuild: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : gpr-names.adb:225
[/usr/local/bin/gprbuild]
System.Assertions.Raise_Assert_Failure at s-assert.adb:46
Gpr.Names.Get_Name_String at gpr-names.adb:225
Gpr.Conf.Get_Or_Create_Configuration_File.Do_Autoconf at gpr-conf.adb:883
Gpr.Conf.Get_Or_Create_Configuration_File at gpr-conf.adb:1481
Gpr.Conf.Process_Project_And_Apply_Config at gpr-conf.adb:2305
Gpr.Conf.Parse_Project_And_Apply_Config at gpr-conf.adb:1815
Gprbuild.Main at gprbuild-main.adb:2438
Main at b__gprbuild-main.adb:946
[/lib/x86_64-linux-gnu/libc.so.6]
0x7f09b421db95
[/usr/local/bin/gprbuild]
0x4d86e8 _start at ???
0xfffffffffffffffe
steve@bionic:\~/Desktop$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-src/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=x86_64-linux-gnu --prefix=/usr/local --enable-languages=c,c++,ada --enable-bootstrap --disable-multilib --enable-shared --enable-shared-host
Thread model: posix
gcc version 9.0.1 20190227 (experimental) (GCC)
steve@bionic:\~/Desktop$ |
Thank you for your test case, we can reproduce. |
i eventually got gpl 2018 to work (since this PR didn't go anywhere). I forget how. Maybe this patch? |
Hello, I've also got his exception in some cases: |
The root cause of the crash is pretty simple: the project Settings is not found, unless you run gprbuild from the same directory. If you want it to be resolved no matter the current working directory, you should import it from tools.gpr with the correct relative path information:
Now the full explanation of why a clean error is not issued in this particular case is a bit involved. It has to do with using a variable from Settings in the declaration of Object_Dir which has a special role in the processing. Do the same with Exec_Dir and you will get an explicit report:
I doubt there is a quick patch to fill this hole :( |
I've been having trouble with gprbuild 2018 so I went back to 2017. Yesterday I tried again. I used the bootstrap process to build a new gprbuild on DragonFly. I had to limit the gprlib libraries to static and static-pic because it failed on relocatable (I didn't know why at the time).
So building the new gtkada 2018 results in this error during the relocatable library building:
Using addr2line, I determined this trace:
which brought me here:
https://github.com/AdaCore/gprbuild/blob/master/src/gprbuild-post_compile.adb#L1713-L1734
Get_Name_String is failing:
Should For_Project.Config.Run_Path_Origin be checked for validity before calling Get_Name_String ?
The text was updated successfully, but these errors were encountered: