I have been looking at trying to resolve random failures of threaded
applications on hppa*-*-hpux11* built with GCC. There are problems
with java and applications linked against libgomp. There are a number
issues.
The first and main issue is libc contains pthread stubs. As a result,
libpthread
> If I change the link line to the following (using libz.la rather than
> -L[path to zlib] -lz):
> ...
> /bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
> +Oentrysched +Odataprefetch +Onolimit -o libpng.la -rpath
> /opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo
>
> /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
> pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
> pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
> pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64
> -L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw
> I agree that we should use +b to embed the path. Is everyone else in
> agreement?
What about the alternative "-L" and "-l" approach which ia64 uses and
I adopted in my original patch? I tried to stay away from using "+b".
Maybe I am missing something but the package which I have built seem
to h
> I suggest neither. I believe that you don't want to try to hardcode
> the full path of libraries. It is better to use "+b" to set the embedded
> path. This is equivalent to the -rpath option when GNU ld is used.
The other way to set the embedded path is to use "-L" and "-l", and
NOT use "+b".
> Dependent libraries for hppa64* is funky.
>
> $ cd /tmp/a
> $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
> $ elfdump -L lib1.sl | head
> 0 Needed libc.2
> 1 Soname lib1.sl.0
> $ cd /tmp/b
> $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc
> $ elfdump -L lib2.sl |
to add to the confusion, this is my original patch.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2002-07-09 John David Anglin <[EMAIL PROTECTED]>
* libtool.m4
> The toplevel configure script sets "LD=ld". The ld used by the GCC check
> in the opcodes directory has the line
>
> test -z "$LD" && LD="$ac_prog"
The above line comes from libtool.m4. If we set LD="" in the toplevel
configure script, the libtool script then sets LD to ld program used by
(613) 990-0752 (FAX: 952-6605)
2001-05-31 John David Anglin <[EMAIL PROTECTED]>
* ltcf-c.sh (archive_cmd): Use gcc to link shared archives when
$with_gcc = yes.
--- ltcf-c.sh.orig Sun May 20 14:57:40 2001
+++ ltcf-c.sh Thu May 31 18:34:37 2001
@@
> > LD_LIBRARY_PATH is ignored for dependencies of shared libraries.
> > What does work for me, is adding `rpath' options for the relink
> > based on the path in LD_LIBRARY_PATH.
>
> How about setting LD_RUN_PATH?
I haven't tried it but the manpage says that it is only used when rpath
isn't used
> As posted in the libgcj mailing list, the problem is that libgcc_s is
> not a libtool library, so libtool can't do its magic of handling
> to-be-installed libraries. Setting LD_LIBRARY_PATH so that libgcc_s
I tried setting LD_LIBRARY_PATH and then running libtool to build
the Array_1 testsuite
> > However, it is not without problems since there isn't a shared
> > version of libgcc for hpux yet.
>
> Indeed, this would be a problem, because on HP-UX libtool would drop
> libgcc from the link command when creating shared libraries, given
> that HP-UX is one of those platforms in which it i
> > As a result, the pre-install version of Array_1 (lt-Array_1) has an
> > incorrect runtime location for libgcc_s.so.0. It uses the old
> > version in the install directory rather than the new version in the
> > gcc build directory.
>
> As posted in the libgcj mailing list, the problem is that
> It also makes libtool use -nostdlib, which is most definitely wrong
> without a definition of output_verbose_link_cmd. It appears to me
> that you have simply copied the definitions from ltcf-cxx.sh, where
> output_verbose_link_cmd is set whenever the compiler is GCC.
> ltcf-c.sh doesn't.
I di
This seems to be a libtool problem. Array_1 is one of the testsuite
programs for libjava. It is built with libtool. The problem appears
appears to be that in building the relink command for the Array_1
script, libtool doesn't add `rpath' options for gcc (in this case
gcj) `-B' options. It only
g' is in $LIT$:
__objc_class_name_NXConstantString| 4|extern|data |$LIT$
Any suggestions on what needs to change to fix this?
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6605
> Installing patch PHCO_22536 might help. HP-UX 10.20 sh has a known bug
> leaving droppings in /tmp WRT here-documents.
Yup, the problem has been around for years. The patch is installed and
doesn't help.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Rese
> With the current cvs source for the branch, I find that libtool is leaving
> an incredible amount of litter in /usr/tmp. I am getting hundreds if
> not thousands of files like:
>
> # cat sh17740.3
> int main() { return 0; }
> # cat sh17740.2
> # Name of the non-PIC object.
> non_pic_
Forwarded message:
>From dave Thu Apr 26 13:01:45 EDT 2001
Subject: libtool adds multiple `-lg' options linking [v3] testsuite
To: [EMAIL PROTECTED]
Date: Thu, 26 Apr 2001 13:01:45 -0400 (EDT)
From: "John David Anglin"
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Conten
19 matches
Mail list logo
