This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gnome 2.8.0 and external dependencies


Gerrit P. Haase wrote:

  The new updates are based on libtool-1.5.10
now which seems to work fine here.

Yay!


That is the reason why we must use libtool-1.5.10, there are data symbols in some Glib objects which are tagged with .rdata and when you try to dynamically load them -> bang. I got always this crash when GConf loaded gthread.dll. Now I don't find any 'R' tags in /usr/lib, run this: for i in `ls *.dll.a`; do echo $i && nm $i | grep ' R '; done in /usr/lib.

Well, that's not conclusive. All that means is that so far, one of the following is true:
(1) the libs have not been recompiled with a new gcc (>= 3.3.3-3)
OR
(2) the libs do not have any const data items WHICH THEMSELVES CONTAIN pointers to other exported DATA items in their public interface.


libtool-1.5.x (x<10) had the flaw where it deliberately violated #2. Newer gcc's obligingly put the container item into .rdata -- where the runtime-pseudo-reloc magic couldn't update the *contained* references to the other DATA items. We're actually just sidestepping the issue ("Don't do that") by convincing libtool-1.5.10 to declare the container non-const, so it goes into .data where pseudo-reloc can muck with it.

That doesn't mean some other package might currently be violating #2. It just means that if so, this mythical other package hasn't yet been recompiled using gcc-3.3.3-3 or newer.

Keep your fingers crossed.

What changed is that there are these .rdata tags in symbols. That may well cause such problems. Charles explained exactly why the error happens and that it must be changed in the source, we should look into all the libraries if there are .rdata rtags and then try to patch the sources so that gcc puts these symbols in data sections instead.

Yep. See above. gmodule-related stuff might be affected by this issue, since glib does its own symbol marshalling and lookup-table definitions.


Now since Charles has found a workaround and we have the new libtool version we can run the apps and debug them. What to do if you even cannot start the application? The only thing I saw was that loading gthread gives my a crash.

maybe caused by attempts to use thread local storage? I'm not sure how mature the combination of gcc/binutils/cygwin/libtool/tls is.


--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]