-lcrt0.o not found

[rogermc2]

Mac OSX 10.15.7
XCode 12.0
GNATMAKE Community 2020 (20200429-84)

Compile and link work well until link fails with library not found for -lcrt0.o using gnatmake, gprbuild and GPS.

[zertovitch]

This is needed for the following sub-package in HAL's body (file src/hal.adb):

package Non_Standard is

  procedure Sys (Command : String; Result : out Integer);

  function Directory_Separator return Character;

end Non_Standard;

For GNAT this is implemented in the file src/hal-non_standard.adb with external references to GNAT's run-time. This method works on Windows and Linux, with the same file. I'm not sure why the linker doesn't find crt0.o on your installation but I remember having seen similar issues discussed on GNAT for Mac for other projects. Perhaps this question has already appeared on comp.lang.ada .

[rogermc2]

Thanks, I think I have come across this problem in the distant past but can't recall how I overcame it. Googling indicates that its a long standing problem with Mac OSX.
I found this which is interesting:
https://github.com/skaht/Csu-85

Searching comp.lang.ada indicates using -nostdlib, thanks to Simon Wright, which seems familiar.
Incorporating -nostdlib did get rid of the -lcrt0.o error.
However, link now fails with:
ld: -rpath can only be used when creating a dynamic final linked image
-rpath is not used in the gpr file and I can't find it in other hac files.

[zertovitch]

If you want to test HAC, you could, in your copy of HAC, make a bogus body for the procedure in src/hal-non_standard.adb and make the function return '/'. Then you'll have a fully functional HAC, except for Shell_Execute.

[rogermc2]

Thanks for your advice but I'm a bit confused.
What sort of "bogus body" for procedure Sys?
I tried changing it to null but that didn't seem to work;
I changed function Directory_Separator to return '/'
but link still fails with:
ld: -rpath can only be used when creating a dynamic final linked image
This message usually occurs 3 times successively; but occasionally twice.

[zertovitch]

Try replacing the contents of src/hal-non_standard.adb with:

with Ada.Text_IO;

separate (HAL) package body Non_Standard is

  procedure Sys (Command : String; Result : out Integer) is
  begin
    Ada.Text_IO.Put_Line ("Caution: HAL.Shell_Execute disabled");
    Result := -1;
  end Sys;

  function Directory_Separator return Character is
  begin
    return '/';
  end Directory_Separator;

end Non_Standard;

Then HAC is completely free of non-Ada dependencies.

[rogermc2]

Thanks, but using the replacement I still get:
ld: -rpath can only be used when creating a dynamic final linked image
However, it only occurs once instead of two or three time previously.

[zertovitch]

Hopefully one of the following will be helpful:

1. Removing the strings "-static" in hac.gpr, then build.
2. Removing all compilation product (.o, .ali, and other files), or just the whole obj directory, then build.
3. Put "procedure Zero is begin null; end;" into a file zero.adb in the hac directory, then run "gprbuild -P hac zero.adb" and see what happens.

[rogermc2]

gprbuild -P hac zero.adb produced many undefined symbols.

gprbuild: failed command was: /opt/gnat/2020/bin/gcc zero.o b__zero.o -nostdlib -g -L/System/Volumes/Data/Ada_Source/hac/obj/debug/ -L/System/Volumes/Data/Ada_Source/hac/obj/debug/ -L/opt/gnat/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/adalib/ /opt/gnat/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/adalib/libgnat.a -Wl,-rpath,@executable_path//obj/debug -Wl,-rpath,/opt/gnat/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/adalib -o /System/Volumes/Data/Ada_Source/hac//zero

I tried messing around with a copy of hac.gpr
Finally found that the problem is due to "-nostdlib"
Without "-nostdlib" gprbuild -P hac zero.adb runs to completion without error.
I'm sure that I've used "-nostdlib" in other projects without problem; however, I think not for pure Ada projects.
I'll check other projects that use "-nostdlib" to try and figure a solution.

Here's an example:
build.gpr.zip

[zertovitch]

That's fine - but "-nostdlib" (or its contrary) is not in hac.gpr.
At this point it is clearly an issue of the GNAT setup you have on your Mac - and how to build successfully a "hello world"-class program with it - and it's not related to the HAC project or to the hac.gpr project file.

[rogermc2]

I agree.
I finally fixed it following your advice.
When I deleted "-static", I left my added "-nostdlib" in.
Removing "-nostdlib" (with "-static" deleted) resulted in a successful build.
Thanks again for your help, much appreciated.

[zertovitch]

If you find a convenient combination of switches (or absence thereof...) that make the build successful (hopefully with the few dependencies to GNAT's run-time discussed previously) and you are confident it will likely work on most Mac setups, I could add a "OS_Kind" switch in hac.gpr, like here:
https://github.com/zertovitch/globe-3d/blob/master/globe_3d.gpr

[rogermc2]

Excellent idea.
So far it seems the only changes needed for Mac is the absence of "-static".
With only the deletion of "-static" hac built successfully and the examples all worked progressively through gallery.
I have only attempted to build hac under OSX Catalina, but I have another Mac restricted to High Sierra, so I'll try hac under High Sierra as a check on another Mac setup.
As the "-lcrt0.o not found" problem has been around with Macs for many years, I am fairly confident that your suggested "OS_Kind" switch should work on most Mac setups.
I'll try hac under High Sierra and report the result.
If there are any other tests that might help, please advise.
Thanks.

[rogermc2]

hac under Mac OSX High Sierra built without problem after removing "-static" from hac.gpr.
"../hac gallery.adb" ran successfully through all examples.
It would also be good to update the user manual to include OSX in addition to Linux and Windows.

[zertovitch]

Next step it the testing part: in the ./test directory: ../hac -v2 all_silent_tests.adb ...

[rogermc2]

All 32 tests passed on Catalina.

One test failed on High Sierra:
raised ADA.IO_EXCEPTIONS.LAYOUT_ERROR : a-tiflau.adb:120 instantiated at a-tiflio.adb:49 instantiated at hal.ads:37
*** Command: [../hac strings.adb ] FAILED ***.

Summary:
31 successes
1 failures
-------[ HAC ]------- VM interpreter done after 48.781179000 seconds.
-------[ HAC ]------- Execution of all_silent_tests.adb completed.
-------[ HAC ]------- Maximum stack usage: 47 of 4000000 units, around 0%.

[rogermc2]

Some preliminary debugging of strings.adb under High Sierra.
Fails on Avagrado test.
With Avagrado test commented out, next failure occurs at
for i in -5 .. 5 loop
...
r := Real (i) * 1.0e20;
Adding debug code
put_line ("image(r) 3a: " & Real'image(r));
generates
image(r) 3a: -5.00000000000000000E+20
but
put_line ("image(r) 3b: " & image(r));
fails with
raised ADA.IO_EXCEPTIONS.LAYOUT_ERROR : a-tiflau.adb:120 instantiated at a-tiflio.adb:49 instantiated at hal.ads:37

Hope this is of interest.

[zertovitch]

It seems that a string for containing the output in the Image function in HAL is too small.
Is there a chance to get a trace-back?
Anyway there are not so many temp strings for numerical output in hal.adb.
Perhaps you can figure out which increased size would be convenient for Catalina. Are floating-point numbers different on that machine (non Intel CPU/FPU), perhaps ?

[rogermc2]

How do I get a " trace-back".
Catalina, which is the later OSX version, is OK. Its High Sierra that has the problem.
I'm investigating further although I don't have much experience in this area.
Presumably the problem is to do with the High Sierra SDK.

[rogermc2]

I tracked the problem to HAL.HAC_Image (F : Real)
-- Image without exponent (E).
-- If the number is too large for this layout, a Layout_Error
-- is raised and we call Image_with_exponent.
RIO.Put (s, F, Exp => 0);

which fails for F: -5.00000000000000000E+20
with
raised ADA.IO_EXCEPTIONS.LAYOUT_ERROR

However, this LAYOUT_ERROR is supposed to be caught by an exception handler which should call Image_with_exponent.
The code works for F/10.0**7

I tried a Put_Line from the exception handler
and also tried changing
exception
when Ada.Text_IO.Layout_Error to when others
but neither of these worked.
That is, it seems to me that the exception is not being caught by the HAC_Image exception handler?

I even tried declaring HAL_Exception and
exception
when others =>
raise HAL_Exception with "HAC_Image Layout_Error: Number too large";
But even this didn't catch it.

I'm wondering if I'm using the wrong GNAT?

[zertovitch]

• For getting trace-backs there is the "-Es" binder option - activated in hac.gpr but apparently disabled in your setup.

• Perhaps there is again a LAYOUT_ERROR raised within Image_with_exponent. It should not work that way, but who knows?... A way to verify it is to add some "Put"'s in the code - absent a trace-back.

• Or your GNAT setup is in a mode where exception handlers are disabled (some people use that mode).
  You could try the following in order to verify that point:

  with Ada.Text_IO;
  
  procedure Catch_Me is
  
    use Ada.Text_IO;
  
    procedure Boom is
    begin
      raise Layout_Error;
    end;
  
  begin
    Boom;
  exception
    when Layout_Error => Put ("Caught");
  end;
  

[rogermc2]

I think I've found the problem.
I was using GNAT 2021 which I built from source
Switched to GNAT 2020 which is a binary distribution
Now all 32 tests pass

[zertovitch]

Great!
Now (commit 6c440cc) hac.gpr has a scenario variable HAC_OS.
For you just need to build without setting that variable, it's useful only on Linux.

[rogermc2]

Mac OSX High Sierra
Pulled latest hac.
Built using GPS without problem
../hac -v2 all_silent_tests.adb
All 32 tests passed.

GPS created the command:
gprbuild -d -eL -P/Ada_Source/hac/hac.gpr --config=/Ada_Source/default.cgpr -s -XHAC_OS=Any -XHAC_Build_Mode=Debug

Using terminal:
gprbuild -P hac was also successful.