Subject: link failed in load of ADT file ..

From: [email-masked] (Bruce Taneja.)
Date: Tue, 28 Jun 1994 18:47:13 -0400 (EDT)

Hi folks,

I wonder if having substantially large code for input & output
functions for a defined data type emp_DT  (just like circle)
causes problems ...??

++++++++++++++++++++++++++++++++++++++++
     define function emp_DT_in
    (language = "c", returntype = emp)
     arg is (char16)
      as "/resrch2/postgres/bruce/emp.o" \g

     define function emp_DT_out
    (language = "c", returntype = emp)
     arg is (emp)
    as "/resrch2/postgres/bruce/emp.o" \g

               define type emp_DT
               (internallength = 568,        <<<<<<<<<<<<<< length = 568.
                input =emp_DT_in, output=emp_DT_out) \g

   create ntable(emp = emp_DT) \g

   append ntable (emp = "(23,John,(),(),())"::emp_DT) \g
+++++++++++++++++++++++++++++

*  append ntable (emp = "(23,John,(),(),())"::emp_DT) \g

Query sent to backend is "append ntable (emp = "(23,John,(),(),())"::emp_DT) "
WARN:Jun 28 18:36:45:Load of file /resrch2/postgres/bruce/emp.o failed: link fai
led!

---------------

I assure you that the file IS there compiled with the same options which
successfully compile circle.c ........

even :
* load  "/resrch2/postgres/bruce/emp.o" \g

Query sent to backend is "load  "/resrch2/postgres/bruce/emp.o" "
WARN:Jun 28 18:45:53:Load of file /resrch2/postgres/bruce/emp.o failed: link fai
led!
-------------------

All comments appreciated !
Bruce!

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "[email-masked]"

   If this fails, send mail to "[email-masked]" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================

---

From: "Andrew K. Yu" <[email-masked]>
Date: Tue, 28 Jun 1994 17:36:05 -0700

> functions for a defined data type emp_DT  (just like circle)

shouldn't. I've seen object files of sizes in megabyte range being loaded in
successfully.

> WARN:Jun 28 18:36:45:Load of file /resrch2/postgres/bruce/emp.o failed: link fai
	
Without info on the version of postgres and the platform you're running on,
I can't tell you much except the following general observations:

1. Top causes for failure:
	- object file cannot be opened because the postgres backend does not
	  have access to or permission on the file. (You'll get a "stat failed"
	  instead of "link failed" message, however.)
	- object file not compiled correctly (eg. need -c and/or special
	  options for a specific platform)
	- object file contain symbols defined in postgres backend already
	  (on version 4.2/Ultrix, you get a "multiply defined" message)
	- /tmp does not have enough space for the intermediate relocated
	  object (for versions <= 4.1)
	- you had a bad day

2. If you're still using version 4.1 or early, I'd strongly recommend you
   upgrade to version 4.2 since the dynamic loading mechanism has been 
   revamped. (And I haven't heard any complaint about it not working on
   4.2, yet!) In 4.2, the dynamic loader uses the OS's native dynamic
   loading/share library facilities except for Ultrix (which uses my dynamic
   loading package). 
	
-andrew

---

From: [email-masked] (J.Plewe)
Date: Wed, 29 Jun 94 09:58:40 +0200

> WARN:Jun 28 18:45:53:Load of file /resrch2/postgres/bruce/emp.o failed: link fai

Hmmm, there are more strange things about that. When I just compile

  cc -s -Ipostgres/include circle.c 

and then

  os:/work/plewe[20] spog
  Warning: Assuming database plewe
  connected to backend database plewe
  spog > load "/work/plewe/circle.o"
  FATAL: no response from backend: detected in PQexec
  spog: detected a fatal error, exiting...
  os:/work/plewe[21] 

You see?

When I now do a dummy linker run, e.g.

  ld -o foo.o circle.o

then I get

  os:/work/plewe[21] spog 
  connected to backend database plewe
  spog > load "/work/plewe/foo.o"
  LOAD successful

The difference between circle.o and foo.o is that foo.o seems to
be better prepared for dynamic loading, unless I do not understand
the mechanisms.

  os:/work/plewe[23] nm circle.o
           U _atof
  00000000 T _circle_in
  000001ac T _circle_out
           U _palloc
           U _point_dt
  00000240 T _pt_in_circle
           U _sprintf

  os:/work/plewe[22] nm foo.o
  00002000 d __DYNAMIC
  00000020 T _circle_in
  000001cc T _circle_out
  00002090 D _edata
  00002090 B _end
  000004a0 T _etext
  00000260 T _pt_in_circle
  00000020 t circle.o

Ah, my system is SunOS4.1.3 and Postgres 4.2.

Remaining strange, Joerg

*********************************************************************
Dipl. Phys. Joerg Plewe               [email-masked]
MPI fuer molekulare Physiologie
Rheinlanddamm 201
44139 Dortmund
Germany                               +49 (0)231 1206 384
*********************************************************************

---

From: "Andrew K. Yu" <[email-masked]>
Date: Wed, 29 Jun 1994 11:20:52 -0700

>   cc -s -Ipostgres/include circle.c 

I do not understand what the -s is doing here.

[ foo.o stuff deleted ]
> When I now do a dummy linker run, e.g.

the file you need to specify in the "as" clause of the define function 
command must be a shared library in 4.2/SunOS4.x. This extra step generates
the shared library (since -Bdynamic is the default) and call it "foo.o".

> be better prepared for dynamic loading, unless I do not understand

your observation is correct. circle.o is not a shared library and is not
ready for dynamic loading.

> Ah, my system is SunOS4.1.3 and Postgres 4.2.

Thanks-- vital info.

-andrew