--- Comment #65 from ubizjak at gmail dot com 2010-03-11 12:18 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #64 from howarth at nitro dot med dot uc dot edu 2010-03-11
03:30 ---
Can someone please close this as fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #63 from developer at sandoe-acoustics dot co dot uk
2010-01-22 09:59 ---
this is fixed AFAIK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #62 from andreast at gcc dot gnu dot org 2009-11-18 07:37
---
Subject: Bug 39888
Author: andreast
Date: Wed Nov 18 07:37:04 2009
New Revision: 154283
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154283
Log:
2009-11-18 Iain Sandoe
PR other/39888
--- Comment #61 from andreast at gcc dot gnu dot org 2009-11-18 07:36
---
Subject: Bug 39888
Author: andreast
Date: Wed Nov 18 07:36:12 2009
New Revision: 154282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154282
Log:
2009-11-18 Iain Sandoe
PR other/39888
--- Comment #60 from developer at sandoe-acoustics dot co dot uk
2009-10-02 10:39 ---
Reg test results:
powerpc-apple darwin8 :
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00141.html
i686-apple-darwin9: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00142.html
compare without p
--- Comment #59 from developer at sandoe-acoustics dot co dot uk
2009-10-02 08:17 ---
Created an attachment (id=18691)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18691&action=view)
libext patch with ext on as default, debug flag removed and white space changes
removed.
This sh
--- Comment #58 from mrs at apple dot com 2009-10-01 19:18 ---
Seems reasonable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #57 from developer at sandoe-acoustics dot co dot uk
2009-10-01 17:22 ---
(In reply to comment #56)
> Okay. So no problem. What do you think is the best way to default on
> libgcc-ext? Just using...
I'm reg-testing on powerpc-apple-d8, i686-apple-d9 and x86_64-apple-d10
wit
--- Comment #56 from howarth at nitro dot med dot uc dot edu 2009-10-01
13:59 ---
Okay. So no problem. What do you think is the best way to default on
libgcc-ext? Just using...
Index: gcc/config/darwin.h
===
--- gcc/config
--- Comment #55 from developer at sandoe-acoustics dot co dot uk
2009-10-01 08:36 ---
(In reply to comment #54)
> The new libgcc_s.dylib appears to be only of the native target architecture...
it's best thought of not as "new" but "different" - it's the target for the
Makefile libgcc_s
--- Comment #54 from howarth at nitro dot med dot uc dot edu 2009-09-30
23:38 ---
The new libgcc_s.dylib appears to be only of the native target architecture...
file libgcc_s.dylib
libgcc_s.dylib: Mach-O 64-bit dynamically linked shared library x86_64
file libgcc_s.1.dylib
libgcc_s.1.
--- Comment #53 from howarth at nitro dot med dot uc dot edu 2009-09-30
23:36 ---
Iain,
We seem to be producing an extra libgcc shared library with the new patch.
In darwin_objdir/stage1-x86_64-apple-darwin10.0.0/libgcc, I see...
libgcc_ext.10.4.dylib libgcc_ext.10.5.dylib libg
--- Comment #52 from developer at sandoe-acoustics dot co dot uk
2009-09-30 19:54 ---
(In reply to comment #51)
> Looks much better than past versions... Seems like muse-shared-libgcc-ext
> should be the default, and possibly that we don't even need the switch?
thanks Mike, I'll do a
--- Comment #51 from mrs at apple dot com 2009-09-30 19:45 ---
Looks much better than past versions... Seems like muse-shared-libgcc-ext
should be the default, and possibly that we don't even need the switch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #50 from developer at sandoe-acoustics dot co dot uk
2009-09-30 16:58 ---
Created an attachment (id=18677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18677&action=view)
further simplified lib ext patch
after some discussion with Ian Lance Taylor, I took another loo
--- Comment #49 from developer at sandoe-acoustics dot co dot uk
2009-09-28 09:02 ---
(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #46)
> > It bootstraps fine here on x86_64-apple-darwin10 as well.
> It does ; but there's an error message about -R
--- Comment #48 from developer at sandoe-acoustics dot co dot uk
2009-09-28 07:47 ---
(In reply to comment #47)
> (In reply to comment #46)
> It bootstraps fine here on x86_64-apple-darwin10 as well.
It does ; but there's an error message about -R not being supported any more
str
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2009-09-26
20:36 ---
(In reply to comment #46)
> more than 20 lines... but not too too much.
>
Iain,
It bootstraps fine here on x86_64-apple-darwin10 as well. Why don't you
submit it
to gcc-patches after regtesting but a
--- Comment #46 from developer at sandoe-acoustics dot co dot uk
2009-09-26 17:28 ---
Created an attachment (id=18657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657&action=view)
much simplified version of the ext patch
OK. Jack made a Good Catch there...
There is a much s
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2009-09-26
05:51 ---
It appears that the build structure required by the patch will prohibit
factoring out the additional ver files. The patch proposed in
r152192-4-5-trunk-patch.diff is as small as I can make it since the ver
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2009-09-26
02:55 ---
This isn't tested yet, but I think if we also change...
--- libgcc-ext.patchfink2 2009-09-25 20:17:05.0 -0400
+++ libgcc-ext.patchfink3 2009-09-25 22:53:12.0 -0400
@@ -387,7 +3
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2009-09-26
00:59 ---
The r152192-4-5-trunk-patch.diff is your 152135-4-5-trunk-patch.diff.txt with
the correction of the...
+EXLIB_64FLAG = .
in libgcc/config/i386/t-darwin64 and the use of -unexported_symbols_list for
EXLIB
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2009-09-26
00:54 ---
Created an attachment (id=18652)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18652&action=view)
patch modified to use unexport on libgcc-ext files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #41 from howarth at nitro dot med dot uc dot edu 2009-09-25
23:51 ---
Iain,
I just puzzled out a solution for keeping the symbols constantly updated for
libgcc-ext*. We make the following changes to your patch...
1) The files gcc/config/rs6000/darwin-libgcc-ext-32B-10.4.
--- Comment #40 from developer at sandoe-acoustics dot co dot uk
2009-09-25 19:25 ---
(In reply to comment #39)
> EXLIB_64FLAG = i386
close ;) -- it should be EXLIB_64FLAG = .
(I think)
build is nearly finished on x86_64-apple-darwin9
i686-apple-darwin10 build completed and is reg-t
--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-09-25
19:16 ---
Iain,
I believe I see the problem with the x86_64-apple-darwin10 build. The
multilib subdirectory for the 32-bit binaries is named i386. So you need...
EXLIB_64FLAG = i386
instead of...
EXLIB_64FLAG
--- Comment #38 from developer at sandoe-acoustics dot co dot uk
2009-09-25 10:54 ---
(In reply to comment #37)
> I just noticed that I have been neglecting to pass
> --enable-version-specific-runtime-libs to configure. What should be the impact
> of that on the build (since I did get t
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-09-25
10:44 ---
I just noticed that I have been neglecting to pass
--enable-version-specific-runtime-libs to configure. What should be the impact
of that on the build (since I did get the expected libgcc-ext.10.4/5 files)
--- Comment #36 from developer at sandoe-acoustics dot co dot uk
2009-09-25 10:07 ---
(In reply to comment #34)
> The build on i686-apple-darwin10 is going better but has a glitch. A no
> time during the different stages of the bootstrap are libgcc_s.10.4.dylib and
> libgcc_s.10.5.d
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-09-25
02:19 ---
Created an attachment (id=18647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18647&action=view)
i686-apple-darwin10 build log with patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2009-09-25
01:20 ---
Iain,
The build on i686-apple-darwin10 is going better but has a glitch. A no
time during the different stages of the bootstrap are libgcc_s.10.4.dylib and
libgcc_s.10.5.dylib created. For example, in
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2009-09-24
23:48 ---
Iain,
With those missing files added, the build still fails for
x86_64-apple-darwin10. I've uploaded the failed build log in case you recognize
where the build is going astray.
--
http://gcc.gnu.o
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2009-09-24
23:47 ---
Created an attachment (id=18645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18645&action=view)
build failure on x86_64-apple-darwin10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-24 22:42 ---
(In reply to comment #30)
>I am getting the build failure on x86_64-apple-darwin10 of...
*** No rule to make target
> `../../../../gcc-4.5-20090924/libgcc/../gcc/config/i386/darwin-libgcc-ext-32B-1
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2009-09-24
22:33 ---
Iain,
I am getting the build failure on x86_64-apple-darwin10 of...
# Early copyback; see "all" above for the rationale. The
# early copy is necessary so that the gcc -B options find
# the right start
--- Comment #29 from developer at sandoe-acoustics dot co dot uk
2009-09-24 20:55 ---
Created an attachment (id=18644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18644&action=view)
updated patch for 4-5 trunk
(i) the added .ver files are (as yet) unchanged - so some newer (las
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-09-24
13:15 ---
Iain,
You patch is showing some bit rot against current gcc trunk. Can you upload
an updated version that applies cleanly against the current sources?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-09-24
13:06 ---
I don't see why your current patch should present a problem for darwin10. My
understanding is that all of the symbols in libgcc-10.5 were moved into
libSystem
and they are ignored if present in libgcc rega
--- Comment #26 from developer at sandoe-acoustics dot co dot uk
2009-09-24 07:46 ---
(In reply to comment #24)
> I am confused why libgcc_ext needs to be built as 10.4/10.5 versions. Aren't
the _ext is versioned - precisely because the symbols included in the OS
version changes betwee
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-09-23
23:45 ---
Okay. I see my confusion now on the usage of -unexported_symbols_list. We still
need to carefully consider the implications of...
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html
going into gcc tr
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-09-23
21:18 ---
I am confused why libgcc_ext needs to be built as 10.4/10.5 versions. Aren't
all of the symbols to be exported by libgcc_ext from post libgcc-10.5? If so,
wouldn't a shared library exporting all of the sym
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-09-23
21:06 ---
(In reply to comment #20)
> Subject: Re: TLS emutls not linked to automatically on Darwin
>
> On Sep 23, 2009, at 8:50 AM, howarth at nitro dot med dot uc dot edu
> wrote:
> > What about just leveragin
--- Comment #22 from mrs at apple dot com 2009-09-23 20:52 ---
Subject: Re: TLS emutls not linked to automatically on Darwin
On Sep 23, 2009, at 11:40 AM, howarth at nitro dot med dot uc dot edu
wrote:
> Also I don't see why the macro above has any advantages over just
> using -une
--- Comment #21 from mrs at apple dot com 2009-09-23 20:49 ---
Subject: Re: TLS emutls not linked to automatically on Darwin
On Sep 23, 2009, at 9:19 AM, howarth at nitro dot med dot uc dot edu
wrote:
> What we need is an approach that links in libgcc.a or libgcc_s to a
> dummy lib
--- Comment #20 from mrs at apple dot com 2009-09-23 20:48 ---
Subject: Re: TLS emutls not linked to automatically on Darwin
On Sep 23, 2009, at 8:50 AM, howarth at nitro dot med dot uc dot edu
wrote:
> What about just leveraging PIC-code libgcc.a on darwin by creating a
> libgcc_e
--- Comment #19 from mrs at apple dot com 2009-09-23 20:43 ---
Subject: Re: TLS emutls not linked to automatically on Darwin
On Sep 22, 2009, at 8:02 PM, howarth at nitro dot med dot uc dot edu
wrote:
> Doesn't this imply that you can't make force libgcc to be found before
> libSyste
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-09-23
18:57 ---
Hmmm...
MULTIOSSUBDIR := $(shell if test $(MULTIOSDIR) != .; then echo /$(MULTIOSDIR);
fi)
in gcc-4.4.1/libgcc/Makefile.in survives into the generated Makefile intact. So
perhaps something like...
SHLI
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-09-23
18:40 ---
(In reply to comment #6)
>
> The hiding trick goes something like:
>
> #define NOT_HERE_BEFORE_10_6(sym) \
> extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
> __at
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-09-23
17:53 ---
Would a construct like...
SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
-install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME) \
-single_module -o $(SHLIB_DIR)/$(SHLIB_SON
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-23
16:50 ---
Look at gcc/libgcc/config/t-slibgcc-darwin, in particular...
SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
-install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME) \
-single
--- Comment #14 from developer at sandoe-acoustics dot co dot uk
2009-09-23 16:36 ---
(In reply to comment #12)
> However your current
> approach isn't scalable (which was Mike's complaint).
anything that requires an action per added function is "non-scalable" in that
way.
the only ac
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-09-23
16:28 ---
Actually, the files darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver in
gcc/config/rs6000 and gcc/config/i386 must be used in that manner (with
-exported_symbols_list instead of -unexported_symbols_list)
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-23
16:19 ---
Iain,
Rereading Nick's reply here...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
I guess using libgcc_s would work under Snow Leopard. However your current
approach isn't sca
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2009-09-23 16:00 ---
(In reply to comment #10)
> What about just leveraging PIC-code libgcc.a on darwin by creating a
> libgcc_ext
> with only a dummy routine and a linkage to the FSF libgcc.a. When creating
> libgcc_ext,
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-23
15:50 ---
What about just leveraging PIC-code libgcc.a on darwin by creating a libgcc_ext
with only a dummy routine and a linkage to the FSF libgcc.a. When creating
libgcc_ext, the ld option -unexported_symbols_list
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-23
03:02 ---
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first.
Mike,
Remember on llvm-dev Nic
--- Comment #8 from mrs at apple dot com 2009-09-22 21:17 ---
I meant the idea that libSystem has new symbols in it is relevant only to
darwin10. The system libgcc_s is present on older OSes, so those aspects are
still relevant. Yeah, to solve that problem one would either have to have
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-22
19:20 ---
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first.
OK. If I understand this from t
--- Comment #6 from mrs at apple dot com 2009-09-22 18:56 ---
I wonder if we could just trim out the symbols from libgcc that are in
libSystem, and arrange for gcc's installed libgcc to be found first.
Advantage, simplicity, less target specific work, easy to understand.
Downside, OS u
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:15 ---
testresults:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02886.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02887.html
and to engage the facility you need to build your program with
" -mu
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:07 ---
Sorry I got the attachments and the comment in the wrong order...
The basic issue is that TLS emulation needs to be linked just once in an
executable - but so does exception handling. Exception handli
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:05 ---
Created an attachment (id=17771)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17771&action=view)
patch against 4.5 trunk
also needs the added files
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:04 ---
Created an attachment (id=17770)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17770&action=view)
added files for the libgcc_ext patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:03 ---
Created an attachment (id=17769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17769&action=view)
patch for 4.4-branch (and 4.4.0 release)
don't forget to add the version files.
--
http://gc
65 matches
Mail list logo
