Ticket #1255 (closed patch: fixed)

Opened 12 years ago

Last modified 11 years ago

fix PARROT_EXPORT visibility=default for gcc other than 4.x

Reported by: jkeenan Owned by: jkeenan
Priority: normal Milestone:
Component: configure Version: 1.7.0
Severity: medium Keywords:
Cc: infinoid particle Language:
Patch status: new Platform:

Description (last modified by coke) (diff)

This ticket transfers into Trac an issue originally discussed in the RT system at  RT #62010.

In that ticket, Donald Hunter said:

"This patch fixes a problem with gcc 3.4.6 on Linux where -fvisibility=hidden is detected as supported but attribute((visibility("default"))) is not used for PARROT_EXPORT. The setting for export visibility was hard-coded for gcc > 4.0 so I changed it to be a new test based on the detection of support for -fvisibility=hidden

"I created a new file for the config step because it has to happen after config/auto/warnings.pm and there's no other relevant file to put it in."

However, a number of Parrot developers (including myself) were skeptical of the need for a new configuration step as proposed in that RT. Discussion was inconclusive.

infinoid, can you take this ticket?

Thank you very much.

kid51

Change History

  Changed 12 years ago by coke

  • description modified (diff)

  Changed 12 years ago by jkeenan

  • owner set to jkeenan
  • status changed from new to assigned

I'm not sure how we should proceed with this ticket. Tonight I built Parrot at r47499 with gcc-3.3 -- the closest I could get to the OP's conditions -- on Linux/i386.

I could not locate the string 'visibility' in the output of make, nor could I find it in lib/Parrot/Config/Generated.pm.

In the absence of any guidance, I will mark this ticket as rejected after the release next week.

Thank you very much.

kid51

follow-up: ↓ 5   Changed 11 years ago by chromatic

I'm not sure of the need to support GCC 3.x anymore anyhow. GCC 4.0 is at least five years old now.

follow-up: ↓ 7   Changed 11 years ago by nick@…

On Thu, Aug 19, 2010 at 06:10:04AM -0000, Parrot wrote:
> #1255: fix PARROT_EXPORT visibility=default for gcc other than 4.x

> Comment(by chromatic):
> 
>  I'm not sure of the need to support GCC 3.x anymore anyhow.  GCC 4.0 is at
>  least five years old now.

http://openbsd.org/47.html

    The system includes the following major components from outside suppliers:

        * Xenocara (based on X.Org 7.4 with xserver 1.6.5 + patches, freetype 2.3.9, fontconfig 2.6.0, Mesa 7.4.2, xterm 250 and more)
        * Gcc 2.95.3 (+ patches) and 3.3.5 (+ patches)
        * Perl 5.10.1 (+ patches)

[etc]


So current OpenBSD still only has gcc 3.3

Nicholas Clark

in reply to: ↑ 3 ; follow-up: ↓ 6   Changed 11 years ago by fperrad

Replying to chromatic:

I'm not sure of the need to support GCC 3.x anymore anyhow. GCC 4.0 is at least five years old now.

The official "current release" of MinGW is GCC 3.4.5.

Note: the latest Strawberry Perl is shipped with mingw/gcc 4.4.3.

François

in reply to: ↑ 5   Changed 11 years ago by doughera

Replying to fperrad:

Replying to chromatic:

I'm not sure of the need to support GCC 3.x anymore anyhow. GCC 4.0 is at least five years old now.

Parrot builds fine with gcc-3.4.6 as supplied by the current Debian stable ("lenny"). I have also used 3.4.x on SPARC/Solaris. In all cases I have tried, Configure.pl correctly tests -fvisibility=hidden and correctly deduces that it doesn't work.

I strongly suspect that the original report was in error, and barring additional supporting evidence from the original poster, this ticket should simply be closed as "rejected".

in reply to: ↑ 4 ; follow-up: ↓ 11   Changed 11 years ago by jkeenan

Replying to nick@…:

 http://openbsd.org/47.html The system includes the following major components from outside suppliers: * Xenocara (based on X.Org 7.4 with xserver 1.6.5 + patches, freetype 2.3.9, fontconfig 2.6.0, Mesa 7.4.2, xterm 250 and more) * Gcc 2.95.3 (+ patches) and 3.3.5 (+ patches) * Perl 5.10.1 (+ patches)

So current OpenBSD still only has gcc 3.3 Nicholas Clark

Nick,

Do you have any access to an OpenBSD system on which you could attempt to build Parrot (HEAD or latest release) using gcc 3.3?

Thank you very much.

kid51

follow-ups: ↓ 9 ↓ 10   Changed 11 years ago by nick@…

On Sat, Aug 21, 2010 at 12:35:53AM -0000, Parrot wrote:

>  Do you have any access to an OpenBSD system on which you could attempt to
>  build Parrot (HEAD or latest release) using gcc 3.3?

I have an account on the gcc compile farm, details here
http://gcc.gnu.org/wiki/CompileFarm

Given that their accounts policy is

    If you are working on a piece of free software (GCC or any other) and
    need ssh access to the farm for compilation, debug and test on various
    architectures you may apply for a GCC Compile Farm account.

and I asked for an account to facilitate porting perl 5 to architectures I
don't otherwise have access to, I'm guessing that anyone interested in doing
the same for parrot would be able to get an account.

The only OpenBSD machine there is OpenBSD sparc64 (gcc64 in the list)

I tried with parrot head. Configure works, and most of the build, so there
doesn't seem to be a problem with parrot on gcc 3.3. However, the build
fails with a SEGV, which is repeatable:

$ gmake runtime/parrot/library/PGE.pbc
perl -e "" > compilers/pge/PGE/builtins_gen.pir
./parrot -o runtime/parrot/library/PGE.pbc compilers/pge/PGE.pir
./parrot runtime/parrot/library/PGE/Perl6Grammar.pir --output=compilers/pge/PGE/builtins_gen.pir compilers/pge/PGE/builtins.pg
gmake: *** [runtime/parrot/library/PGE.pbc] Segmentation fault (core dumped)
gmake: *** Deleting file `runtime/parrot/library/PGE.pbc'


$ perl -e "" > compilers/pge/PGE/builtins_gen.pir
$ ./parrot -o runtime/parrot/library/PGE.pbc compilers/pge/PGE.pir
$ gdb --args ./parrot runtime/parrot/library/PGE/Perl6Grammar.pir --output=compilers/pge/PGE/builtins_gen.pir compilers/pge/PGE/builtins.pg
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.6"...
(gdb) r
Starting program: /home/nick/Parrot/parrot/parrot runtime/parrot/library/PGE/Perl6Grammar.pir --output=compilers/pge/PGE/builtins_gen.pir compilers/pge/PGE/builtins.pg

Program received signal SIGSEGV, Segmentation fault.
0x0000000047c8d058 in u.0 ()
   from /home/nick/Parrot/parrot/blib/lib/libparrot.so.2.7.0
(gdb) where
#0  0x0000000047c8d058 in u.0 ()
   from /home/nick/Parrot/parrot/blib/lib/libparrot.so.2.7.0
#1  0x0000000047877928 in trace_system_areas (interp=0x500a5800, 
    mem_pools=0x455c2200) at src/gc/system.c:149
#2  0x000000004787613c in Parrot_gc_trace_root (interp=0x500a5800, 
    mem_pools=0x455c2200, trace=GC_TRACE_FULL) at src/gc/mark_sweep.c:226
#3  0x0000000047873e0c in gc_ms_trace_active_PMCs (interp=0x500a5800, 
    trace=GC_TRACE_FULL) at src/gc/gc_ms.c:1420
#4  0x0000000047871d20 in gc_ms_mark_and_sweep (interp=0x500a5800, flags=2)
    at src/gc/gc_ms.c:540
#5  0x0000000047870764 in Parrot_gc_mark_and_sweep (interp=0x500a5800, flags=2)
    at src/gc/api.c:690
#6  0x00000000478741ec in gc_ms_more_traceable_objects (interp=0x500a5800, 
    mem_pools=0x455c2200, pool=0x455c2e00) at src/gc/gc_ms.c:1513
#7  0x0000000047874570 in gc_ms_get_free_object (interp=0x500a5800, 
    mem_pools=0x455c2200, pool=0x455c2e00) at src/gc/gc_ms.c:1592
#8  0x000000004787229c in gc_ms_allocate_pmc_header (interp=0x500a5800, 
    flags=0) at src/gc/gc_ms.c:674
#9  0x000000004786fa04 in Parrot_gc_new_pmc_header (interp=0x500a5800, flags=0)
    at src/gc/api.c:326
#10 0x00000000478d5164 in get_new_pmc_header (interp=0x500a5800, base_type=40, 
    flags=0) at src/pmc.c:447
#11 0x00000000478d48a8 in Parrot_pmc_new (interp=0x500a5800, base_type=40)
    at src/pmc.c:163
#12 0x000000004787fa1c in Parrot_pcc_build_sig_object_from_op (
    interp=0x500a5800, signature=0x498f5140, raw_sig=0x4bde23a0, 
    raw_args=0x460b9668) at src/call/args.c:317
#13 0x0000000047803e48 in Parrot_set_args_pc (cur_opcode=0x460b9668, 
    interp=0x500a5800) at src/ops/core_ops.c:15546
#14 0x00000000478d8550 in runops_slow_core (interp=0x500a5800, 
    runcore_unused=0x4ba3b880, pc=0x460b9668) at src/runcore/cores.c:647
#15 0x00000000478d6c7c in runops_int (interp=0x500a5800, offset=24)
    at src/runcore/main.c:237
#16 0x0000000047887130 in runops (interp=0x500a5800, offs=24)
    at src/call/ops.c:127
#17 0x000000004787f710 in Parrot_pcc_invoke_from_sig_object (
    interp=0x500a5800, sub_obj=0x4fe7a540, call_object=0x4fe7b800)
    at src/call/pcc.c:325
#18 0x00000000478644fc in Parrot_ext_call (interp=0x500a5800, 
    sub_pmc=0x4fe7a540, signature=0x47b39178 "->P") at src/extend.c:322
#19 0x00000000478c4fec in run_sub (interp=0x500a5800, sub_pmc=0x4fe7a540)
    at src/packfile.c:741
#20 0x00000000478c53bc in do_1_sub_pragma (interp=0x500a5800, 
    sub_pmc=0x4fe7a540, action=PBC_MAIN) at src/packfile.c:833
#21 0x00000000478c5a38 in do_sub_pragmas (interp=0x500a5800, self=0x455c3f00, 
    action=PBC_MAIN, eval_pmc=0x0) at src/packfile.c:997
#22 0x00000000478d0c84 in PackFile_fixup_subs (interp=0x500a5800, 
    what=PBC_MAIN, eval=0x0) at src/packfile.c:5052
#23 0x0000000047a022e0 in imcc_run_pbc (interp=0x500a5800, output_file=0x0, 
    argc=3, argv=0xfffffffffffcb570) at compilers/imcc/main.c:413
#24 0x000000000010202c in main (argc=4, argv=0xfffffffffffcb568)
    at src/main.c:149


It's not a big-endian 64 bit issue, given that PPC 64bit linux works:

All tests successful, 9 tests and 660 subtests skipped.
Files=356, Tests=12432, 925 wallclock secs (374.80 cusr + 37.74 csys = 412.54 CPU)
$ uname -a
Linux gcc40 2.6.26-2-powerpc64 #1 SMP Thu May 13 07:29:31 UTC 2010 ppc64 GNU/Linux

I'm afraid that I really don't have time to help further on this one.
I assume that the best way to proceed is for someone who does have the time
to apply for a compile farm account and take it from there.

Nicholas Clark

in reply to: ↑ 8   Changed 11 years ago by jkeenan

Replying to nick@…:

I have an account on the gcc compile farm, details here  http://gcc.gnu.org/wiki/CompileFarm I'm afraid that I really don't have time to help further on this one. I assume that the best way to proceed is for someone who does have the time to apply for a compile farm account and take it from there. Nicholas Clark

Nick, thanks for that very generous deployment of your time taken to investigate this!

kid51

in reply to: ↑ 8   Changed 11 years ago by doughera

Replying to nick@…:

Program received signal SIGSEGV, Segmentation fault. 0x0000000047c8d058 in u.0 () from /home/nick/Parrot/parrot/blib/lib/libparrot.so.2.7.0 (gdb) where #0 0x0000000047c8d058 in u.0 () from /home/nick/Parrot/parrot/blib/lib/libparrot.so.2.7.0 #1 0x0000000047877928 in trace_system_areas (interp=0x500a5800, mem_pools=0x455c2200) at src/gc/system.c:149

That's the SPARC stackwalking code, which doesn't crash under Solaris. Many years ago I think I also tried it under Linux/SPARC, and it didn't crash their either. See TT #271 for more details and a link to a tentative patch.

in reply to: ↑ 7 ; follow-up: ↓ 12   Changed 11 years ago by darbelo

Replying to jkeenan:

Do you have any access to an OpenBSD system on which you could attempt to build Parrot (HEAD or latest release) using gcc 3.3?

I seem to be the de-facto 'platform champion' for OpenBSD this days, so I should point out that I do mostly-regular building and testing of parrot's svn HEAD on either the latest OpenBSD release or CVS snapshots for both i386 and amd64 (Which I should note has switched to a 4.x gcc) on a mostly regular basis. In the last two years, parrot has steadily built fine for me with the system gcc, and I have been able to fix it whenever it didn't.

On the other hand, OpenBSD's system compiler is not a stock gcc, so I can't really speak for an unpatched gcc 3.x install.

in reply to: ↑ 11 ; follow-up: ↓ 13   Changed 11 years ago by jkeenan

Replying to darbelo:

Replying to jkeenan: I should point out that I do mostly-regular building and testing of parrot's svn HEAD on either the latest OpenBSD release or CVS snapshots for both i386 and amd64 (Which I should note has switched to a 4.x gcc) on a mostly regular basis. In the last two years, parrot has steadily built fine for me with the system gcc, and I have been able to fix it whenever it didn't.

I believe that on any given OS, the most important C compiler with which to test whether Parrot builds successfully is the vendor-supplied C compiler. Given that, and given darbelo's report, I don't see any compelling reason for us to worry about this issue any further.

So unless someone objects, I will close this ticket by Wed Aug 25.

Thank you very much.

kid51

in reply to: ↑ 12   Changed 11 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to fixed

Replying to jkeenan:

So unless someone objects, I will close this ticket by Wed Aug 25.

No objections recorded. Closing ticket.

Note: See TracTickets for help on using tickets.