Skip to content
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

Open
jrmarino opened this issue Jul 5, 2018 · 13 comments
Open

GPL 2018 asserts during relocatable library building #45

jrmarino opened this issue Jul 5, 2018 · 13 comments
Assignees

Comments

@jrmarino
Copy link

jrmarino commented Jul 5, 2018

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:

/raven/bin/gprbuild  -j3 -m -p  -XLIBRARY_TYPE=relocatable -Psrc/gtkada.gpr
gprbuild: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : gpr-names.adb:225
Call stack traceback locations:
0xc01fcf 0x8d33a0 0x5b8756 0x52a35a 0x5f2c73 0x5f13f8 0x5f1752 0x5f0b47 0x40bc78 0x42b09d 0x40451d

gmake[1]: *** [Makefile:85: build_library_type/relocatable] Error 4
gmake[1]: Leaving directory '/construction/gtkada/gtkada-gpl-2018-src'

Using addr2line, I determined this trace:

0xc01fcf /construction/gcc7/.build/gcc/ada/rts/s-assert.adb:46
0x8d33a0 /construction/gprbuild/gprbuild-gpl-2018-src/gpr/src/gpr-names.adb:225 (discriminator 5)
0x5b8756 /construction/gprbuild/gprbuild-gpl-2018-src/src/gprbuild-post_compile.adb:1726 (discriminator 9)
0x52a35a /construction/gprbuild/gprbuild-gpl-2018-src/src/gprbuild-post_compile.adb:3348
0x5f2c73 /construction/gprbuild/gprbuild-gpl-2018-src/src/gprbuild-post_compile.adb:4943
0x5f13f8 /construction/gprbuild/gprbuild-gpl-2018-src/src/gprbuild-post_compile.adb:3600
0x5f1752 /construction/gprbuild/gprbuild-gpl-2018-src/gpr/src/gpr.adb:2289
0x5f0b47 /construction/gprbuild/gprbuild-gpl-2018-src/src/gprbuild-post_compile.adb:3621
0x40bc78 /construction/gprbuild/gprbuild-gpl-2018-src/src/gprbuild-main.adb:2638
0x42b09d /construction/gprbuild/gprbuild-gpl-2018-src/obj/debug/b__gprbuild-main.adb:901
0x40451d ??:?

which brought me here:
https://github.com/AdaCore/gprbuild/blob/master/src/gprbuild-post_compile.adb#L1713-L1734

      ---------------------------
      -- Write_Run_Path_Option --
      ---------------------------

      procedure Write_Run_Path_Option is
         List : constant Name_List_Index :=
                  For_Project.Config.Run_Path_Option;
      begin
         if Opt.Run_Path_Option and then List /= No_Name_List then
            Write_Name_List (Exchange_File, Run_Path_Option, List);
            Put_Line (Exchange_File,
                      Library_Label (Gprexch.Run_Path_Origin));
            Put_Line (Exchange_File,
                      Get_Name_String (For_Project.Config.Run_Path_Origin));

            if For_Project.Config.Separate_Run_Path_Options then
               Put_Line
                 (Exchange_File,
                  Library_Label (Gprexch.Separate_Run_Path_Options));
            end if;
         end if;
      end Write_Run_Path_Option;

Get_Name_String is failing:

            Put_Line (Exchange_File,
                      Get_Name_String (For_Project.Config.Run_Path_Origin));

Should For_Project.Config.Run_Path_Origin be checked for validity before calling Get_Name_String ?

@jrmarino
Copy link
Author

jrmarino commented Jul 5, 2018

by the way, the code entered on Feb 22:
b862085#diff-fac2fda8c4b2ea31626ee1835f548a55

@t-14
Copy link
Contributor

t-14 commented Jul 5, 2018

Should For_Project.Config.Run_Path_Origin be checked for validity before calling Get_Name_String

Most likely yes. Can you tell us what value are you getting there in your case?

@jrmarino
Copy link
Author

jrmarino commented Jul 5, 2018

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.

@jrmarino
Copy link
Author

jrmarino commented Jul 6, 2018

this code is in gprbuild-link.adb:

         if Main_Proj.Config.Run_Path_Origin /= No_Name
           and then Get_Name_String (Main_Proj.Config.Run_Path_Origin) /= ""
         then
            Rpaths_Relative_To
              (Rpaths,
               Main_Proj.Exec_Directory.Display_Name,
               Main_Proj.Config.Run_Path_Origin);
         end if;

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.

@jrmarino
Copy link
Author

jrmarino commented Jul 6, 2018

This might be solution:

--- src/gprbuild-post_compile.adb.orig  2018-05-25 06:23:18 UTC
+++ src/gprbuild-post_compile.adb
@@ -1718,7 +1718,10 @@ package body Gprbuild.Post_Compile is
          List : constant Name_List_Index :=
                   For_Project.Config.Run_Path_Option;
       begin
-         if Opt.Run_Path_Option and then List /= No_Name_List then
+         if Opt.Run_Path_Option and then
+            List /= No_Name_List and then
+            For_Project.Config.Run_Path_Origin /= No_Name
+         then
             Write_Name_List (Exchange_File, Run_Path_Option, List);
             Put_Line (Exchange_File,
                       Library_Label (Gprexch.Run_Path_Origin));

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.

@jrmarino
Copy link
Author

jrmarino commented Jul 9, 2018

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.

--- src/gprbuild-post_compile.adb.orig  2018-05-25 06:23:18 UTC
+++ src/gprbuild-post_compile.adb
@@ -1719,11 +1719,13 @@ package body Gprbuild.Post_Compile is
                   For_Project.Config.Run_Path_Option;
       begin
          if Opt.Run_Path_Option and then List /= No_Name_List then
-            Write_Name_List (Exchange_File, Run_Path_Option, List);
-            Put_Line (Exchange_File,
-                      Library_Label (Gprexch.Run_Path_Origin));
-            Put_Line (Exchange_File,
-                      Get_Name_String (For_Project.Config.Run_Path_Origin));
+            if For_Project.Config.Run_Path_Origin /= No_Name then
+               Write_Name_List (Exchange_File, Run_Path_Option, List);
+               Put_Line (Exchange_File,
+                         Library_Label (Gprexch.Run_Path_Origin));
+               Put_Line (Exchange_File,
+                         Get_Name_String (For_Project.Config.Run_Path_Origin));
+            end if;

             if For_Project.Config.Separate_Run_Path_Options then
                Put_Line

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.

@jrmarino
Copy link
Author

anyone?

@Blady-Com
Copy link

Blady-Com commented Feb 27, 2019

Hello,
I achieve to make a reproducer with Gnoga (see attached simplified files):
test28.zip

$ 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.
HTH, Pascal.

@steve-cs
Copy link

steve-cs commented Feb 28, 2019

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$ 

@t-14
Copy link
Contributor

t-14 commented Feb 28, 2019

Thank you for your test case, we can reproduce.

@jrmarino
Copy link
Author

i eventually got gpl 2018 to work (since this PR didn't go anywhere). I forget how. Maybe this patch?
https://github.com/jrmarino/ravensource/blob/master/bucket_D7/gprbuild/patches/patch-src_gprbuild-link.adb

@t-14 t-14 assigned rmorier and unassigned lambourg and rmorier Feb 28, 2019
@Blady-Com
Copy link

Hello, I've also got his exception in some cases:
gprbuild: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : gpr-names.adb:181

@rmorier
Copy link
Contributor

rmorier commented Mar 4, 2019

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:

with "../settings.gpr";

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:

tools.gpr:1:06: unknown project file: "settings.gpr"
tools.gpr:6:21: unknown package or project "Settings"
gprbuild: "test28/tools/tools.gpr" processing failed

I doubt there is a quick patch to fill this hole :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants