From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cacf2a126e0a3921,start X-Google-Attributes: gid103376,public From: swhalen@netcom.com (Steve Whalen) Subject: GNAT 3.10p OS/2 Assert/Library bug? Date: 1997/10/27 Message-ID: X-Deja-AN: 285256082 Sender: swhalen@netcom19.netcom.com Organization: ? Newsgroups: comp.lang.ada Date: 1997-10-27T00:00:00+00:00 List-Id: First, I really appreciate what ACT does for Ada95 and I really like the GNAT compilers, so... Since I'm NOT a paying customer of ACT (yet!), I try to avoid wasting their time and try to be as self reliant as possible (I actually RTFM, etc.), but I've run across what appears to be a genuine (but obscure) bug. If there is any way I can look up this bug in ACT's bug list myself to see if they already know about it, please let me know because I'd be happy to do that. But so far I haven't figured out a way to do so (and haven't seen this particular bug mentioned on CLA or on GNAT / Chat). If it's NOT possible for me to look this up in ACT's bug list, then I would like to get input from the folks on CLA regarding what appears to be a bug in GNAT 3.10p for OS/2 - emx (and also GNAT 3.07 for MsDos - DJGPP) (but which is NOT visible in GNAT 3.10p Linux, etc.). I don't want to report it if it's already known, because I presume it would take ACT "some" amount of time to figure out they already know about it, or it's already fixed in an upcoming release, etc. ===> Bug Summary (example source code at end of message) <=== Symptom: gnatmake blows up with "undefined symbol" error if you: 1) are running GNAT 3.10p OS/2 - emx (or GNAT 3.07 MsDos - DJGPP) 2) create a package / library file (.o and .ali) that has a pragma Assert in it, but compile with Asserts disabled (no -gnata), as you would when you finishing testing and put the package into your library directory for re-use. 3) later, you compile a program with assertions enabled (-gnata) AND with the package from step 2. The link step will fail with one or more "undefined symbol" errors. (i.e. you're mixing a pre-compiled package that had a pragma Assert in it, but was compiled with assertions disabled, with a program containing a pragma Assert, and trying to compile the new program with assertions enabled (-gnata) while using the pre-compiled package). ===> Workaround <=== Use "ar" to add EVERY .o file in system adalib directory to the gnat.a library file distributed with GNAT OS/2. That way, when GNAT fails to list the s-assert.o file (along with a couple of others) in it's explicit .o link list (in b_xxxxx.c), the linker finds them in the gnat.a library anyway. This seems to work for me (I hope I'm not creating some other, even more obscure problem by doing this...). I suspect this bug may not have been noticed before, because on most machines GNAT does NOT appear to produce an explicit list of all the .o files to include in the link step (i.e. in the b_xxxxxx.c file it generates). I suspect that if the other platforms produced such a list, it would be wrong too, under these circumstances. Anyway, this pragma Assert situation, seems to confuse GNAT (GnatBind / BindGen? / ALI table build flag setting?). Since running into this has made me think about it, I realized I don't even know (and can't tell from the GNAT user guide) whether or not using the -gnata flag when compiling a program *should* enable the pragma Asserts that may be "hiding" in modules already in the re-use library that were compiled with assert/debug DISabled. I personally think they should remain DISabled... GNAT should probably do something a bit more elegant than creating the "undefined symbol" problem. And I don't think this qualifies as a "side affect" of the pragma Assert, at least in the usual sense, as mentioned in the documentation. ===> sample code and test run <=== FIRST ===> gnatmake -c testpack gcc -c testpack.ads --------TestPack.ads--------------------- package TestPack is type Small_Record is record s1 : Integer; s2 : Integer; end record; type Big_Record is record b1 : Integer; b2 : Integer; b3 : Integer; b4 : Integer; end record; pragma Assert (Big_Record'Size = 2 * Small_Record'Size); end TestPack; ----------------------------------------- THEN ===> gnatmake -gnata testprog gcc -c -gnata testprog.adb gnatbind -x testprog.ali gnatlink testprog.ali ----------TestProg.adb------------------- with TestPack; procedure TestProg is b : TestPack.Big_Record; s : TestPack.Small_Record; begin b.b1 := 1; s.s1 := 2; pragma Assert (b.b1 = s.s1); end TestProg; ----------------------------------------- RESULT ===> under GNAT 3.10p OS/2 - emx and GNAT 3.07 MsDos - DJGPP GNATLINK 3.10p (970814) Copyright 1996 Free Software Foundation, Inc. gcc -c b_testprog.c gcc b_testprog.o e:/emx/gnatlib\system.o e:/emx/gnatlib\s-tasoli.o (continued) e:/emx/gnatlib\s-taspda.o e:/emx/gnatlib\s-stalib.o (continued) ./testpack.o ./testprog.o -L./ -Le:/emx/gnatlib\ (continued) -L\ -lgnat -lgnat -o testprog.exe ./testprog.o: Undefined symbol (continued) _system__assertions__raise_assert_failure referenced (continued) from text segment gnatmake: *** link failed. under GNAT 3.10p Linux (compile OK, runs correctly): ./testprog raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : testprog.adb:8 -----------the end----------------------- -- {===----------------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===----------------------------------------------------------------------===}