Re: rebaseall and cygstdc++-6.dll
On 10/09/2011 02:57, Chris Sutcliffe wrote: > Hi All, > > Just a heads up around an issue I encountered with rtorrent after > executing rebaseall. I ran in to some forking issues so I executed > rebaseall after which rtorrent started to crash constantly during > various operations. Through trial and error I narrowed it down to > cygstdc++-6.dll being rebased. As a result I updated rebaseall to > exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'". > > I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I > figured I should share my findings in case someone else runs in to a > similar issue. I finally nailed this one down. Stray base relocs against references to symbols in discarded COMDAT sections remaining in the .eh_frame data cause the stack unwind lookup to get lost. Sourceware CVS is down right now but I'll be sending the attached to binutils when it's working again, and I've started building a 4.5.3-3 release. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
'screen' stackdump very often.
Sometimes it started properly but usually not. $ screen --version Screen version 4.00.03 (FAU) 23-Oct-06 $ screen 2 [main] screen 2876 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1058 [main] screen 2876 open_stackdumpfile: Dumping stack trace to screen.exe.stackdump 2 [main] screen 3944 exception::handle: Exception: STATUS_ACCESS_VIOLATION 17847 [main] screen 3944 open_stackdumpfile: Dumping stack trace to screen.exe.stackdump 2 [main] screen 3112 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1048 [main] screen 3112 open_stackdumpfile: Dumping stack trace to screen.exe.stackdump 283 [main] screen 3972 exception::handle: Exception: STATUS_ACCESS_VIOLATION 35719 [main] screen 3972 open_stackdumpfile: Dumping stack trace to screen.exe.stackdump 2 [main] screen 3488 exception::handle: Exception: STATUS_ACCESS_VIOLATION 14700 [main] screen 3488 open_stackdumpfile: Dumping stack trace to screen.exe.stackdump 2 [main] screen 3292 exception::handle: Exception: STATUS_ACCESS_VIOLATION 425 [main] screen 3292 open_stackdumpfile: Dumping stack trace to screen.exe.stackdump 2 [main] screen 3484 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x600, errno 11 fork: Resource temporarily unavailable -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
E484: Can't open file /usr/share/vim/syntax/syntax.vim
$ cat ~/.vimrc syntax on $ vim Error detected while processing /cygdrive/e/home/.vimrc: line1: E484: Can't open file /usr/share/vim/syntax/syntax.vim Press ENTER or type command to continue This issue reported previously: http://cygwin.com/ml/cygwin/2006-07/msg00105.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1
Hi list,
Not sure if this counts as a packaging issue so I'm sending it here first.
The problem I'm having is that the above-mentioned libraries all have
libstdc++ ('-lstdc++' to be precise) listed as a dependent lib in the .la
files that are generated by libtool during compilation (and subsequently
installed into /usr/lib):
> /usr/lib/libgdk-x11-2.0.la:dependency_libs=' /usr/lib/libpangocairo-1.0.la
> -L/usr/lib /usr/lib/libpangoft2-1.0.la -lstdc++ /usr/lib/libpango-1.0.la
> /usr/lib/libXinerama.la /usr/lib/libXi.la /usr/lib/libXrandr.la
> /usr/lib/libXcursor.la /usr/lib/libXcomposite.la /usr/lib/libXext.la
> /usr/lib/libXdamage.la /usr/lib/libXfixes.la /usr/lib/libcairo.la
> /usr/lib/libpixman-1.la /usr/lib/libfontconfig.la /usr/lib/libexpat.la
> /usr/lib/libfreetype.la /usr/lib/libglitz.la -lpng12
> /usr/lib/libxcb-render-util.la /usr/lib/libXrender.la
> /usr/lib/libxcb-render.la /usr/lib/libX11.la /usr/lib/libxcb.la
> /usr/lib/libXau.la /usr/lib/libXdmcp.la /usr/lib/libgdk_pixbuf-2.0.la
> /usr/lib/libgio-2.0.la -lz /usr/lib/libgobject-2.0.la
> /usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la
> /usr/lib/libglib-2.0.la /usr/lib/libpcre.la /usr/lib/libintl.la
> /usr/lib/libiconv.la'
>
> /usr/lib/libpangocairo-1.0.la:dependency_libs=' -L/usr/lib
> /usr/lib/libcairo.la /usr/lib/libpixman-1.la /usr/lib/libglitz.la -lpng12
> /usr/lib/libxcb-render-util.la /usr/lib/libXrender.la
> /usr/lib/libxcb-render.la /usr/lib/libX11.la /usr/lib/libxcb.la
> /usr/lib/libXau.la /usr/lib/libXdmcp.la /usr/lib/libpangoft2-1.0.la
> /usr/lib/libgobject-2.0.la /usr/lib/libgthread-2.0.la
> /usr/lib/libgmodule-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libintl.la
> /usr/lib/libiconv.la -lstdc++ /usr/lib/libpango-1.0.la
> /usr/lib/libgobject-2.0.la /usr/lib/libgthread-2.0.la
> /usr/lib/libgmodule-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libpcre.la
> /usr/lib/libintl.la /usr/lib/libfontconfig.la /usr/lib/libexpat.la
> /usr/lib/libfreetype.la -lz /usr/lib/libiconv.la'
>
> /usr/lib/libpangoft2-1.0.la:dependency_libs=' /usr/lib/libgobject-2.0.la
> -L/usr/lib /usr/lib/libgthread-2.0.la /usr/lib/libgmodule-2.0.la
> /usr/lib/libglib-2.0.la /usr/lib/libintl.la /usr/lib/libiconv.la -lstdc++
> /usr/lib/libpango-1.0.la /usr/lib/libgobject-2.0.la
> /usr/lib/libgthread-2.0.la /usr/lib/libgmodule-2.0.la
> /usr/lib/libglib-2.0.la /usr/lib/libpcre.la /usr/lib/libintl.la
> /usr/lib/libfontconfig.la /usr/lib/libexpat.la /usr/lib/libfreetype.la -lz
> /usr/lib/libiconv.la'
None of the generated DLLs (or their dependencies) actually need libstdc, as
far as I can see they're all plain C:-
> $ cygcheck -v /usr/bin/cyg{gdk-x11-2.0,pangocairo-1.0,pangoft2-1.0}* | grep -i
> stdc
>
> $
These apparently bogus dependencies cause problems for automake however, and
specifically for me when trying to build libgtkpeer from gcj/libjava. Because
libgtkpeer is built entirely from .c files, automake infers the language to be
C and so adds the "--tag=CC" option to the libtool invocation when attempting
to link libgtkpeer.la, but this causes an error, because libtool now can't
find the -lstdc++ dependency:
> libtool: link: rm -fr .libs/libgtkpeer.a .libs/libgtkpeer.dll.a
> .libs/libgtkpeer.la .libs/libgtkpeer.lai
>
> *** Warning: linker path does not have real file for library -lstdc++.
> *** I have the capability to make that library automatically link in when
> *** you link to this library. But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libstdc++ and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/lib/libpng12.dll.a
>
> *** Warning: libtool could not satisfy all declared inter-library
> *** dependencies of module libgtkpeer. Therefore, libtool will create
> *** a static module, that should work as long as the dlopening
> *** application is linked with the -dlopen flag.
> libtool: link: /usr/i686-pc-cygwin/bin/ar rc .libs/libgtkpeer.a
> gnu_java_awt_peer_gtk_CairoSurface.o
For the next gcc release I'm just going to add a note to the README that
you'll have to run
sed -i -e 's/-lstdc++//' \
/usr/lib/lib{gdk-x11-2.0,pangocairo-1.0,pangoft2-1.0}*.la
before you can compile it from source, and that it might be worth backing up
the .la files just in case this -lstdc++ actually is required somewhere, but
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these libs think they need to link against libstdc++?
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1
On 25/09/2011 15:51, Dave Korn wrote: > I'd be happier if this could either be fixed in the distro, or if someone > could tell me why these libs think they need to link against libstdc++? It seems I'm not the first to have run into this problem: http://lists.freedesktop.org/archives/cairo/2009-August/017924.html It may be that some configure options to libpangocairo would enable Qt and hence require libstdc, but the dependency gets added regardless of how it is configured? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1
On 2011-09-25 PM 11:51, Dave Korn wrote: before you can compile it from source, and that it might be worth backing up the .la files just in case this -lstdc++ actually is required somewhere, but I'd be happier if this could either be fixed in the distro, or if someone could tell me why these libs think they need to link against libstdc++? cheers, DaveK lstdc++ is included in postdeps in libtool for some reason. postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt" this postdeps was introduced by output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP "\-L"' but in config.status, postdeps='' postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt' so it seems good. therefore, this problem began from *executing libtool commands*. the variable 'postdeps' is not tagged with "_CXX". resulting in wrong-generated libtool -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 25/09/2011 07:07, Dave Korn wrote:
> Sourceware CVS is down right now but I'll be
> sending the attached to binutils when it's working again,
Yeah, d'oh. Maybe I'll send the file with the actual patch in it, instead
of the fresh diff I tried to generate when CVS wasn't working! Attached, JFTR.
cheers,
DaveK
--- pe-dll.c.orig 2011-09-25 03:11:10.90625 +0100
+++ pe-dll.c 2011-09-25 03:11:10.78125 +0100
@@ -1398,6 +1398,16 @@ generate_reloc (bfd *abfd, struct bfd_li
else if (!blhe || blhe->type != bfd_link_hash_defined)
continue;
}
+ /* Nor for Dwarf FDE references to discarded sections. */
+ else if (bfd_is_abs_section (sym->section->output_section))
+ {
+ /* These are the same section names that
+ _bfd_elf_default_action_discarded chooses to discard
+ relocs against. */
+ if (!strcmp (s->name, ".eh_frame")
+ || !strcmp (s->name, ".gcc_except_table"))
+ continue;
+ }
reloc_data[total_relocs].vma = sec_vma + relocs[i]->address;
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1
On 2011-09-25 PM 11:51, Dave Korn wrote: before you can compile it from source, and that it might be worth backing up the .la files just in case this -lstdc++ actually is required somewhere, but I'd be happier if this could either be fixed in the distro, or if someone could tell me why these libs think they need to link against libstdc++? cheers, DaveK This problem comes from *executing libtool commands* You can see in config.status of pango $ cat config.status|grep postdeps postdeps='' postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt' rm ./libtool ./config.status #we can see *executing libtool commands*. and libtool is auto-generated. and now resulting libtool has ill-tagged postdeps variable $ cat libtool|grep postdeps postdeps="" # don't eliminate duplications in $postdeps and $predeps libs="$predeps $libs $compiler_lib_search_path $postdeps" # $postdeps and mark them as special (i.e., whose duplicates are for pre_post_dep in $predeps $postdeps; do case " $predeps $postdeps " in case " $predeps $postdeps $compiler_lib_search_path " in case " $predeps $postdeps " in case " $predeps $postdeps " in case " $predeps $postdeps " in case " $predeps $postdeps " in for i in $predeps $postdeps ; do postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt" Why we got postdeps instead of postdeps_CXX? Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1
On 25/09/2011 16:42, jojelino wrote:
> lstdc++ is included in postdeps in libtool for some reason.
>
> postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
> -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"
>
> this postdeps was introduced by
> output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 |
> $GREP -v "^Configured with:" | $GREP "\-L"'
>
> but in config.status,
> postdeps=''
> postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
> -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'
> so it seems good.
> therefore, this problem began from *executing libtool commands*.
> the variable 'postdeps' is not tagged with "_CXX". resulting in
> wrong-generated libtool
I think this is just libtool working normally; $postdeps is the current
dependencies for this particular invocation, and internally it's doing
something like "postdeps=${postdeps_${tag}}" so it's setting
postdeps=$postdeps_CXX in response to getting --tag=CXX on the command-line,
isn't it? The underlying cause is more likely to be in the way that the
Makefile.am is setting the libtool control variables, which is probably an
issue for upstream.
(And of course this doesn't show up on Linux, where the linker doesn't
complain about a dynamic library not being found because it can just leave
undefined reference in the final executable to be resolved by ld.so at
runtime. But as soon as you try it on a PE rather than ELF platform...)
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1
[ Fixed dup in subject line! ] On 25/09/2011 16:47, jojelino wrote: > Why we got postdeps instead of postdeps_CXX? My answer to that crossed in the ether with this post, I'll just make one further point explicit: > This problem comes from *executing libtool commands* If a problem arises from executing libtool commands, that usually means that something the user did in Makefile.am has tricked automake into generating incorrect libtool commands in the first place, rather than that an actual libtool bug has just appeared. (Libtool bugs are possible of course, but user errors in automake scripts are more common.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1
On 2011-09-26 AM 12:57, Dave Korn wrote:
I think this is just libtool working normally; $postdeps is the current
dependencies for this particular invocation, and internally it's doing
something like "postdeps=${postdeps_${tag}}" so it's setting
postdeps=$postdeps_CXX in response to getting --tag=CXX on the command-line,
isn't it? The underlying cause is more likely to be in the way that the
Makefile.am is setting the libtool control variables, which is probably an
issue for upstream.
On 25/09/2011 16:42, jojelino wrote:
The latter mail has detail(former one was cancelled but i was already
late). the auto-generated libtool doesn't seem to clobber postdeps for
tag specified. then postdeps would be latter one which should have been
postdeps_CXX.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1
On 2011-09-26 AM 1:00, Dave Korn wrote: This problem comes from *executing libtool commands* If a problem arises from executing libtool commands, that usually means that something the user did in Makefile.am has tricked automake into generating incorrect libtool commands in the first place, rather than that an actual libtool bug has just appeared. (Libtool bugs are possible of course, but user errors in automake scripts are more common.) cheers, DaveK The problem is from pango/opentype/libharfbuzz.la It has .cc source and recognized as needed c++ source file although it is c source. and cc source is compiled with --tag=CXX we should teach libtool cc is c source file. Regards -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Relocation patch for cygwin
On 2011-09-24 AM 5:10, jojelino wrote:
The attached is report gprof produced when invoked *id* . as you can
see, format_process_maps consumes 70% of the lifetime(0.5s with
profiling overhead). this is reproducible whenever we do
open('/proc/self/maps').
the problem is, the cost is too expensive. gnulib should care about
cygwin do sacrifice performance for compatibility.
As a workaround, how about rebuild libintl without capacity of relocatable?
because in cygwin libintl is expected to place in /bin so there's no use
of relocatable.
A bug in profiling code was found and fixed. revised time consumption of
format_process_maps is now 60%.
http://pastebin.com/yYh6fNbS for detailed gprof result.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1
On 25/09/2011 18:41, jojelino wrote: > The problem is from pango/opentype/libharfbuzz.la > It has .cc source and recognized as needed c++ source file although it > is c source. and cc source is compiled with --tag=CXX > we should teach libtool cc is c source file. Or upstream should add an explicit --tag=CC, or rename the file extension. Good catch, that certainly ties in with what that link I found was saying. Hmm, there are two harfbuzzes, one old, one new; one has .cc files, the other .cpp files. It appears that they both do actually use C++ features, but perhaps in a limited way; as long as they don't throw exceptions or use RTTI or any of the standard C++ library functions, they could not need linking against libstdc at all. In that case maybe upstream's solution would be to add "-fno-exceptions -fno-rtti" to the CXXFLAGS and "--tag=CC" to the LDFLAGS. Don't know which code base the distro package is based on though; let's wait and see what Yaakov has to say. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 25 September 2011 02:07, Dave Korn wrote: > I finally nailed this one down. Stray base relocs against references to > symbols in discarded COMDAT sections remaining in the .eh_frame data cause the > stack unwind lookup to get lost. Sourceware CVS is down right now but I'll be > sending the attached to binutils when it's working again, and I've started > building a 4.5.3-3 release. I'm confused, is the issue in binutils or gcc? If the issue is in binutils, is rebuilding gcc going to help? Either way, glad you nailed it! Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Relocation patch for cygwin
On 9/23/2011 4:10 PM, jojelino wrote:
> It fixed the relocation problem. but led performance issue :(
>
> $ time id > /dev/null
>
> real0m0.141s
> user0m0.000s
> sys 0m0.000s
Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-relocation, so only a subset of the
"relocation" code *OUGHT* to be involved -- just enough for any calls to
relocate() to return the passed-in string IIRC.
However...it appears that I MAY have mistakenly uploaded the version I
built WITH relocation enabled (which I generally do for testing
purposes, just to make sure it still works). I'll need to double check.
> The attached is report gprof produced when invoked *id* . as you can
> see, format_process_maps consumes 70% of the lifetime(0.5s with
> profiling overhead). this is reproducible whenever we do
> open('/proc/self/maps').
> the problem is, the cost is too expensive. gnulib should care about
> cygwin do sacrifice performance for compatibility.
I'll double check both libiconv/iconv, and libintl/gettext -- but my
initial suspicions are that only libiconv/iconv was accidentally build
with relocation enabled.
> As a workaround, how about rebuild libintl without capacity of relocatable?
> because in cygwin libintl is expected to place in /bin so there's no use
> of relocatable.
Right, and it is intended that, in the cygwin official packages, both
libiconv and libintl are built without relocation support. If that
isn't true, it's a (cygwin packaging) bug.
I have no opinion on whether perceived slowness in the relocation code
itself, or in cygwin code called BY the relocation code such as
format_process_maps, constitutes a bug either in cygwin or gnulib.
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 25/09/2011 21:31, Chris Sutcliffe wrote: > On 25 September 2011 02:07, Dave Korn wrote: >> I finally nailed this one down. Stray base relocs against references to >> symbols in discarded COMDAT sections remaining in the .eh_frame data cause >> the >> stack unwind lookup to get lost. Sourceware CVS is down right now but I'll >> be >> sending the attached to binutils when it's working again, and I've started >> building a 4.5.3-3 release. > > I'm confused, is the issue in binutils or gcc? If the issue is in > binutils, is rebuilding gcc going to help? Either way, glad you > nailed it! The problem is in binutils, and the fact that it generates base relocs for entries from EH data that should be just ignored. http://sourceware.org/ml/binutils/2011-09/msg00174.html contains more detail, if you want to ask more let's do it on the binutils list. So to answer your question: the gcc language-specific runtime DLLs have to be built using the patched version of binutils, otherwise they break when they get rebased; that's why I'm rebuilding the gcc packages - having already locally rebuilt binutils. This will only be a big issue for anyone who wants to rebuild gcc from source themselves, the new packages I upload to the distro will still work for everyone regardless of what binutils they have installed and/or how or when or where they get rebased. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote: > The problem is in binutils, and the fact that it generates base relocs for > entries from EH data that should be just ignored. > > http://sourceware.org/ml/binutils/2011-09/msg00174.html > contains more detail, if you want to ask more let's do it on the binutils > list. > > So to answer your question: the gcc language-specific runtime DLLs have to > be built using the patched version of binutils, otherwise they break when they > get rebased; that's why I'm rebuilding the gcc packages - having already > locally rebuilt binutils. This will only be a big issue for anyone who wants > to rebuild gcc from source themselves, the new packages I upload to the distro > will still work for everyone regardless of what binutils they have installed > and/or how or when or where they get rebased. Except that this issue doesn't affect only libstdc++, but any C++ library which throws exceptions (as I have seen on my system). So we really do need a patched binutils ASAP. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Relocation patch for cygwin
On 2011-09-26 AM 9:50, Charles Wilson wrote: Well, the libiconv distributed as an official cygwin package *SHOULD* not have been built with --enable-relocation, so only a subset of the "relocation" code *OUGHT* to be involved -- just enough for any calls to relocate() to return the passed-in string IIRC. However...it appears that I MAY have mistakenly uploaded the version I built WITH relocation enabled (which I generally do for testing purposes, just to make sure it still works). I'll need to double check. there is '-DENABLE_RELOCATABLE=1' in http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/Makefile.in which cannot be affected by `--enable-relocation`. it would have been -DENABLE_RELOCATABLE=@RELOCATABLE@ i think. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall and cygstdc++-6.dll
On 9/26/2011 5:15 AM, Yaakov (Cygwin/X) wrote: On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote: The problem is in binutils, and the fact that it generates base relocs for entries from EH data that should be just ignored. http://sourceware.org/ml/binutils/2011-09/msg00174.html contains more detail, if you want to ask more let's do it on the binutils list. So to answer your question: the gcc language-specific runtime DLLs have to be built using the patched version of binutils, otherwise they break when they get rebased; that's why I'm rebuilding the gcc packages - having already locally rebuilt binutils. This will only be a big issue for anyone who wants to rebuild gcc from source themselves, the new packages I upload to the distro will still work for everyone regardless of what binutils they have installed and/or how or when or where they get rebased. Except that this issue doesn't affect only libstdc++, but any C++ library which throws exceptions (as I have seen on my system). So we really do need a patched binutils ASAP. There is an easy way to identify such libraries ? Just to know if I need to rebuild some of mines . Yaakov Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
