24718 – Shared libgcc not used for linking by default (original) (raw)

Description The Written Word 2005-11-07 19:24:10 UTC

I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit the same problem. While trying to build Perl 5.8.6: $ gmake ...
gcc -v -o libperl.so -shared -fPIC perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc ... /opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2 +Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib -L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc ^^^^^^^^^^^

Notice the "-lgcc -lgcc" at the end of the collect2 command-line, not "-lgcc_s -lgcc_s".

On HP-UX 11.23/PA-RISC, I get: /opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2 -z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib -L/opt/TWWfsw/gcc343r/lib -L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s

Using the HP pre-compiled binary of gcc-4.0.2, I get: /opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2 -z +Accept TypeMismatch -b -o libperl.so -L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/opt/hp-gcc/4.0.2/bin/../lib/gcc -L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. -L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s -lunwind

The "*libgcc" line from the 3.4.3/3.4.4 specs file: *libgcc: %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} %{static|static-libgcc:-lgcc -lgcc_eh -lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M -lunwind}}}} %{!shared-libgcc:-lgcc}

The "*libgcc" line from the 4.0.2 specs file (via -dumpspecs): *libgcc: %{static|static-libgcc:-lgcc -lgcc_eh -lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}}

Is the problem in the "*libgcc" entry? It seems !shared-libgcc is true, though I don't know why. $ /opt/TWWfsw/gcc343/bin/gcc -v Reading specs from /opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as --with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as --with-included-gettext --enable-shared --datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77 --with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343 Thread model: single gcc version 3.4.3 (TWW)

Comment 1 Jim Wilson 2005-11-08 01:41:15 UTC

See the thread on the gcc list discussing this bug. http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html

I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do not see this problem in the FSF sources.

I do not have an ia64-hpux machine, so I can not easily investigate this.

Comment 3 Steve Ellcey 2005-11-08 21:22:03 UTC

I am not convinced that this is a bug. Was there an intentional change between 3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it seems like this might have happened, that in 3.4 (with C) -shared does not imply -shared-libgcc but in 4.0 it does.

Comment 4 The Written Word 2005-11-08 21:49:03 UTC

(In reply to comment #3)

I am not convinced that this is a bug. Was there an intentional change between 3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it seems like this might have happened, that in 3.4 (with C) -shared does not imply -shared-libgcc but in 4.0 it does.

If -shared did not imply -shared-libgcc, why does gcc -shared on HP-UX 10.20/PA, 11.00/PA, 11.11/PA, and 11.23/PA behave as if -shared-libgcc was included? The question is why HP-UX 11.23/IA-64 is different than HP-UX/PA.

Comment 5 wilson@specifix.com 2005-11-09 00:34:16 UTC

Subject: Re: Shared libgcc not used for linking by default

sje at cup dot hp dot com wrote:

------- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ------- I am not convinced that this is a bug.

There is an obvious bug. Have you actually looked at the specs in question? They have %{shared-libgcc ... %{static-libgcc ...}} which can't possibly be right.

However, there is no bug in FSF gcc. I suspect a bug in the gcc sources being distributed from the HP web site. I haven't checked that.

Comment 6 The Written Word 2005-11-09 00:47:47 UTC

(In reply to comment #5)

Subject: Re: Shared libgcc not used for linking by default

sje at cup dot hp dot com wrote:

------- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ------- I am not convinced that this is a bug.

There is an obvious bug. Have you actually looked at the specs in question? They have %{shared-libgcc ... %{static-libgcc ...}} which can't possibly be right.

However, there is no bug in FSF gcc. I suspect a bug in the gcc sources being distributed from the HP web site. I haven't checked that.

As indicated in comment #2, we built gcc-3.4.4 from the FSF sources and still encountered the bug.

Comment 7 Jim Wilson 2005-11-09 01:45:26 UTC

I see the problem now. It is present in the FSF gcc-3.4.x sources.

The problem is that init_gcc_specs in gcc.c rewrites the LIBGCC_SPEC rule. It looks for the first -lgcc, and replaces it with target independent rules for shared and static libgcc.

The config/ia64/hpux.h file redefines LIBGCC_SPEC as #define LIBGCC_SPEC
"%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} -lgcc}
%{!shared-libgcc:-lgcc}"

So after the substitution, we now have %{shared-libgcc ... %{static-libgcc ...}} which is obviously wrong.

If the config/ia64/hpux.h file is changed to look something like #define LIBGCC_SPEC
"%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}} -lgcc" then it will work much better. I think this can be simplified further without loss of functionality to #define LIBGCC_SPEC
"%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc" The important part here is that -lgcc must not appear inside any braces, because it will be substituted by init_gcc_specs.

Alternatively, we could try disabling the init_gcc_specs rewriting for the ia64-hpux target, and then putting the entire rule we want in the config/ia64/hpux.h file, but I don't think that big of a patch is needed.

A better alternative would be deleting the LIBGCC_SPEC rule in config/ia64/hpux.h, but I don't know if that will work. That might result in the libgcc_s_hpux64 file not being used anymore. I also don't know whether that matters. I would guess that the multilibbing support should find and use it automatically, so in theory it shouldn't be needed, but I am unable to check.

gcc-4.0 and later do not have a problem, because they don't define LIBGCC_SPEC in the config/ia64/hpux.h file.

I can't test the suggested patches, as I don't have an ia64-hpux machine.

Comment 8 Steve Ellcey 2005-11-10 00:08:08 UTC

I tried Jim Wilson's suggested changes (with 3.4.4 GCC) but they didn't seem to fix the problem.

I changed LIBGCC_SPEC to:

    #define LIBGCC_SPEC \
            "%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc"

But if I compile with -shared, I still see -lgcc:

    install/bin/gcc -shared -v hi.c -o x.so

    /proj/opensrc/sje/svn/gcc.34/install/libexec/gcc/ia64-hp-hpux11.23/3.4.4

/collect2 +Accept TypeMismatch -b -o x.so -L/proj/opensrc/sje/svn/gcc.34/install /lib/gcc/ia64-hp-hpux11.23/3.4.4 -L/usr/ccs/bin -L/usr/ccs/lib -L/proj/opensrc/s je/svn/gcc.34/install/lib/gcc/ia64-hp-hpux11.23/3.4.4/../../.. /var/tmp//ccJVUul W.o -lgcc -lgcc

If I look at the specs file I see:

*libgcc: %{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc

I am not sure what is going on here.

Comment 9 Jim Wilson 2005-11-10 03:04:27 UTC

Subject: Re: Shared libgcc not used for linking by default

On Wed, 2005-11-09 at 16:08, sje at cup dot hp dot com wrote:

I tried Jim Wilson's suggested changes (with 3.4.4 GCC) but they didn't seem to fix the problem.

Try debugging init_specs where it calls init_gcc_specs. There might be something about the code that is causing it to misbehave for you. Don't configure with --disable-shared, that will prevent this code from doing anything.

It occurred to me that another possible solution is to change init_specs and/or the ia64-hpux LIBGCC_SPEC so that all uses of -lgcc will be replaced instead of just the first one. That would also fix the problem. Looking at the code, I think adding a space before the second -lgcc in the current ia64-hpux LIBGCC_SPEC would do the trick, because that will cause in_sep to be set again.

Comment 10 Steve Ellcey 2005-11-10 18:20:41 UTC

I can't believe I configured with --disable-shared. OK, without that things look better. I changed LIBGCC to "%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc" and I get -lgcc_s on the link command. I am doing a bootstrap/test now and will submit a patch for the 3.4.* branch when I have finished testing.

Comment 11 Steve Ellcey 2005-11-11 21:39:34 UTC

I have run into a problem with my testing, the link line looks good but I get warnings from the HP linker like:

ld: (Warning) Cannot load library symbol table in /proj/opensrc/sje/test2/gcc-ia 64-hp-hpux11.23-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a, it might be mis sing or corrupted. Skipping library /proj/opensrc/sje/test2/gcc-ia64-hp-hpux11.2 3-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a.

because libgcc_eh.a is empty. For some reason on 3.4 this file is completely empty (nm returns nothing) but on ToT the file is mostly empty, but it has a symbol table and empty test/bss/data and debug sections in it. On 3.4 I have no symbol table in the file which is why I get the warning message. I used the same binutils for each compiler so I don't know yet why there is this difference.

Comment 12 The Written Word 2005-11-11 21:58:37 UTC

(In reply to comment #11)

I have run into a problem with my testing, the link line looks good but I get warnings from the HP linker like:

ld: (Warning) Cannot load library symbol table in /proj/opensrc/sje/test2/gcc-ia 64-hp-hpux11.23-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a, it might be mis sing or corrupted. Skipping library /proj/opensrc/sje/test2/gcc-ia64-hp-hpux11.2 3-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a.

because libgcc_eh.a is empty. For some reason on 3.4 this file is completely empty (nm returns nothing) but on ToT the file is mostly empty, but it has a symbol table and empty test/bss/data and debug sections in it. On 3.4 I have no symbol table in the file which is why I get the warning message. I used the same binutils for each compiler so I don't know yet why there is this difference.

Look at gcc/mklibgcc.in in the 4.0 branch. They add a dummy eh_dummy.o file to libgcc_eh.a to work around this. We had Eric Botcazou backport it to the 3.4 branch for us but a PR hasn't been created. I don't know if its considered a safe enough fix. I haven't tested it yet but I'll attach the patch to this PR.

Comment 14 Jim Wilson 2005-11-11 22:15:56 UTC

Subject: Re: Shared libgcc not used for linking by default

On Fri, 2005-11-11 at 13:39, sje at cup dot hp dot com wrote:

------- Comment #11 from sje at cup dot hp dot com 2005-11-11 21:39 ------- I have run into a problem with my testing, the link line looks good but I get warnings from the HP linker like: ld: (Warning) Cannot load library symbol table in

See this patch: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01123.html The first part of it fixes this problem. The second part may not be safe without other changes.

2005-02-19 Zack Weinberg <zack@codesourcery.com>

    * mklibgcc.in: If libgcc_eh.a would be empty, put a dummy
    object inside.
    * config/ia64/hpux.h: Don't define LIBGCC_SPEC.

Comment 15 Steve Ellcey 2005-11-11 23:42:29 UTC

The patch from comment 14 seems to be working fine without any other changes. I have bootstrapped and am currently running the testsuite. Looks OK so far.

Comment 16 Eric Botcazou 2005-11-12 08:17:37 UTC

The patch from comment 14 seems to be working fine without any other changes. I have bootstrapped and am currently running the testsuite. Looks OK so far.

Zack's patch for 4.x doesn't work as-is for 3.4.x because the multilib logic has changed in mklibgcc.in.

Comment 17 Steve Ellcey 2005-11-14 15:44:23 UTC

Eric, can you be more specific about what won't work? The regression testing with Zack's patch seemed to go fine and hand testing some cases looks OK too.

Comment 18 Eric Botcazou 2005-11-14 15:52:42 UTC

Eric, can you be more specific about what won't work? The regression testing with Zack's patch seemed to go fine and hand testing some cases looks OK too.

Do you have a eh_dummy.o file for both -milp32 and -mlp64?

Comment 19 Steve Ellcey 2005-11-14 16:01:42 UTC

Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared.

Comment 20 The Written Word 2005-11-14 16:07:32 UTC

(In reply to comment #19)

Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared.

Odd. We have the latest linker patch installed on our system (PHSS_33349) and applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still gave a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information to the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us.

Looking at Zack's patch, I don't see how eh_dummy.o would get added to libgcc_eh.a on gcc-3.4 without adding it to $libgcc2_eh_static_objs.

Comment 21 Eric Botcazou 2005-11-14 16:09:59 UTC

Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared.

I must have dreamt... could you send to <ebotcazou@libertysurf.fr> the patched 3.4.x mklibgcc.in as well as the generated $objdir/gcc/libgcc.mk? Thanks in advance.

Comment 22 Eric Botcazou 2005-11-14 16:28:16 UTC

Odd. We have the latest linker patch installed on our system (PHSS_33349) and applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still gave a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information to the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us.

It could be nice to compare the versions of 'ar' and 'ranlib' you have.

Comment 23 Steve Ellcey 2005-11-14 16:33:36 UTC

I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib when building GCC:

ar --version GNU ar 2.16.91 20051103 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty.

ranlib --version GNU ranlib 2.16.91 20051103 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty.

Comment 24 The Written Word 2005-11-14 16:59:22 UTC

(In reply to comment #23)

I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib when building GCC:

We're using the system ar/ranlib. I built binutils-2.16 with no patches but ar doesn't work: $ ./ar /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'.

Comment 25 Steve Ellcey 2005-11-14 17:05:42 UTC

I build binutils with --disable-shared and using flex/bison instead of lex/yacc, that is probably why my ar works. I experimented with the use of the system ar/ranlib by just building eh_dummy.o and .a by hand and they look OK to me, I.e. they have a symbol table in them and thus should not get the warning message.

Comment 26 The Written Word 2005-11-14 17🔞53 UTC

(In reply to comment #25)

I build binutils with --disable-shared and using flex/bison instead of lex/yacc, that is probably why my ar works. I experimented with the use of the system ar/ranlib by just building eh_dummy.o and .a by hand and they look OK to me, I.e. they have a symbol table in them and thus should not get the warning message.

Ok, I have a working binutils-2.16 ar. And, binutils-2.16 ar creates a libgcc_eh.a that does not cause linker errors whereas HP as does not, with the same eh_dummy.o file. Replace your libgcc_eh.a in your GCC tree with the version created by the system ar and I expect you'll see the same as me.

Comment 27 Steve Ellcey 2005-11-14 17:26:35 UTC

In your last comment you mention the binutils ar, but later the binutils as. I cannot reproduce the problem by just using the binutils ar command but I can reproduce it using the binutils as (assembler) command. Which assembler are you using when you get the problem.

Comment 28 The Written Word 2005-11-14 17:29:39 UTC

(In reply to comment #27)

In your last comment you mention the binutils ar, but later the binutils as. I cannot reproduce the problem by just using the binutils ar command but I can reproduce it using the binutils as (assembler) command. Which assembler are you using when you get the problem.

Oops. "HP as" -> "HP ar". So, with a eh_dummy.o created from an eh_dummy.c with 'struct eh_dummy;', libgcc_eh.a created by HP ar gives me a linker warning and a libgcc_eh.a created by binutils-2.16 ar does not give me a linker warning.

Comment 29 Steve Ellcey 2005-11-14 17:31:36 UTC

In my comment I meant to say I could reproduce the problem with the HP assembler, but not with the GNU assembler (even if I use the GNU ar). I will test some more combinations.

Comment 30 Steve Ellcey 2005-11-14 17:35:32 UTC

OK, I have reproduced it with GNU as (assembler) and HP ar. Should we bypass the whole issue by putting 'int __libgcc_eh_dummy;' in eh_dummy.o and use that as the 3.4 patch? I am willing to test and submit such a patch.

Comment 31 The Written Word 2005-11-14 17:41:13 UTC

Sure. I don't understand how Zack's patch works but as long as we have a solution that works, fine by me. Eric might be interested in reviewing the patch too.

Comment 32 Steve Ellcey 2005-11-14 17:46:51 UTC

Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to use the same eh_dummy.c file (struct eh_dummy;) as 3.4.

Comment 33 The Written Word 2005-11-14 17:51:30 UTC

(In reply to comment #32)

Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to use the same eh_dummy.c file (struct eh_dummy;) as 3.4.

4.0.2 had the same problem.

Comment 34 Eric Botcazou 2005-11-14 17:51:44 UTC

Sure. I don't understand how Zack's patch works but as long as we have a solution that works, fine by me. Eric might be interested in reviewing the patch too.

The misunderstanding has been cleared with Steve.

Comment 36 Steve Ellcey 2005-12-01 21:03:36 UTC

Fixed and checked in on 3.4 branch in time for 3.4.5.