Subject: Re: gcc options when building DBD:Oracle

From: "Lincoln A. Baxter" <[email-masked]>
Date: Mon, 20 Jun 2005 22:29:07 -0400

Hi Jan,

This looks like something that might be relatively easy to fix in
Makefile.PL.  But I no longer have access to HPUX systems, and never
built DBD-Oracle with gcc on that platform.  I could add your message to
the README.hpux file, but it is becoming less and less necessary to read
this file with newer versions of DBD-Oracle, in which Makefile.PL has
been made much smarter. 

Would you consider sending Tim or me a patch to Makefile.PL that
generates the right $(LD) command (only on HP rp8400, and only for your
version of gcc or later? 

Lincoln

On Mon, 2005-06-20 at 15:36 -0500, [email-masked] wrote:
> Lincoln,
> 
> I recently built DBD:Oracle on an HP rp8400.  Everything worked as expected until I actually issued the "make" command.  Make proceeded as expected until it reached "MakeMaker dynamic_lib" section.  The gcc line in that section failed with the error in the attached text file.  Apparently gcc was not correctly passing the "+b" option to ld.  Instead, it was attempting to interpret the option itself.  It assumed the "+b" was a filename, and that failed because gcc could not find the file.  I ended up adding the "-Xlinker" option before the "+b" and before the "$(LD_RUN_PATH)" in the line in Makefile.  The line now looks like this:
> 
> $(LD) -Xlinker +b -Xlinker "$(LD_RUN_PATH)"  $(LDDLFLAGS) $(LDFROM) $(OTHERLDFLAGS) -o $@ $(MYEXTLIB) $(PERL_ARCHIVE) $(LDLOADLIBS) $(PERL_ARCHIVE_AFTER) $(EXPORT_LIST)
> 
> Running "make" now works correctly.
> 
> Also, "make test" returned the following error when attempting to build the various tests:
> 
> /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libcl.2
> 
> Setting LD_PRELOAD with "export LD_PRELOAD=/usr/lib/libcl.2" corrected this problem, and "make test" worked correctly.
> 
> 
> I didn't see DBD::Oracle documentation on exactly this, so I'm sending this to you.  You may be aware of these items already.  If so, please disregard this.  
> 
> Jon Riekenberg
> 
> 
>