Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Thanks Torrey. I tried a build without $(SMLIB) and $(ICELIB) in SharedXtReqs, but it fails to link due to unresolved symbols (all symbols must be resolved at library link time in DLLs on Windows). I will have to consult with the rest of the Cygwin people to see what we should do now. Thanks again, Harold Torrey Lyons wrote: The issue on Mac OS X is that most shared libraries want to be built as "two-level namespace" images. Two-level namespace images have significant advantages in loading speed, but they require that they have no unresolved symbols when linking the library. This is why the darwinLib.tmpl contains a complete list of every library's dependencies. Unfortunately this causes a problem with two shared libraries, Xt and Xfont. The problem is that these libraries are designed to have certain symbols undefined and to have theses references resolved at application link time by one of various other library choices. In the case of Xt, SM and ICE provide the default resolution of these symbols in darwinLib.tmpl (and cygwin.tmpl), but symbols with the same names from lesstif should be used instead when the application is linked with it. Two-level namespace libraries don't allow you to do that since all symbols get resolved at library link time, not application link time. Thus we fixed this problem by building libXt and libXfont as flat namespace images, which have the same linking semantics that most people on other *nixes are used to. In your case, I suspect that including $(SMLIB) and $(ICELIB) in the following line from cygwin.tmpl is causing your problem: #define SharedXtReqs $(LDPRELIB) $(SMLIB) $(ICELIB) $(XLIBONLY) If Cygwin's linker does not complain when you removed these two, you should be fine. As it is all of the references which are supposed to remain undefined are likely being satisfied at library link time so nothing from lesstif is being included at application link time. --Torrey At 2:43 AM -0400 10/25/03, Harold L Hunt II wrote: Torrey, Looks like you may have had the same sort of trouble that we are now having with regards to building a shared version of the lesstif libraries that link to a shared version of the Xt library. The particular error message, when starting a lesstif app is: XmManager ClassInitialize: XmeTraitSet failed Nicholas Wourms has been looking into this problem (his notes are below) and he seems to think that an OS/X-specific fix may have been made to one of the XFree86 libs to alleviate this problem with lesstif. Do you recall anything related to this problem? If so, could you describe the fix or point us to a message describing the fix? Thanks in advance, Harold *SIGH* I spoke too soon, after building nedit and trying some other tests, I'm experiencing the "XmManager ClassInitialize: XmeTraitSet failed" problem. Apparently the MacOSX people went through this ordeal last year, but unfortunately that doesn't help us. They had two solutions: 1) Pass "-force_flat_namespace" which is part of OSX's proprietary linker. 2) Downgrade to XFree86-4.1 libs of some sort or upgrade to latest cvs. Of course, in-depth information on why this is happening is nonexistant, all I could find were: http://oroborosx.sourceforge.net/faq.html#q5p1 http://www.geocrawler.com/mail/msg.php3?msg_id=8230372&list=8629 Given that information, I'm willing to bet that an OSX-only fix was checked in sometime after July of last year to resolve this. Finding out what it is will be difficult I'm willing to bet. Of course it could just be Xt misbehaving or an auto-import/psuedo-ops failure. Heh, oh well, I'm going to further investigate this tommorrow... Sorry that it isn't working properly :-(. One last thought, perhaps we should CC Brian Ford in on this since another fresh perspective might be good. Cheers, Nicholas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
The issue on Mac OS X is that most shared libraries want to be built as "two-level namespace" images. Two-level namespace images have significant advantages in loading speed, but they require that they have no unresolved symbols when linking the library. This is why the darwinLib.tmpl contains a complete list of every library's dependencies. Unfortunately this causes a problem with two shared libraries, Xt and Xfont. The problem is that these libraries are designed to have certain symbols undefined and to have theses references resolved at application link time by one of various other library choices. In the case of Xt, SM and ICE provide the default resolution of these symbols in darwinLib.tmpl (and cygwin.tmpl), but symbols with the same names from lesstif should be used instead when the application is linked with it. Two-level namespace libraries don't allow you to do that since all symbols get resolved at library link time, not application link time. Thus we fixed this problem by building libXt and libXfont as flat namespace images, which have the same linking semantics that most people on other *nixes are used to. In your case, I suspect that including $(SMLIB) and $(ICELIB) in the following line from cygwin.tmpl is causing your problem: #define SharedXtReqs $(LDPRELIB) $(SMLIB) $(ICELIB) $(XLIBONLY) If Cygwin's linker does not complain when you removed these two, you should be fine. As it is all of the references which are supposed to remain undefined are likely being satisfied at library link time so nothing from lesstif is being included at application link time. --Torrey At 2:43 AM -0400 10/25/03, Harold L Hunt II wrote: Torrey, Looks like you may have had the same sort of trouble that we are now having with regards to building a shared version of the lesstif libraries that link to a shared version of the Xt library. The particular error message, when starting a lesstif app is: XmManager ClassInitialize: XmeTraitSet failed Nicholas Wourms has been looking into this problem (his notes are below) and he seems to think that an OS/X-specific fix may have been made to one of the XFree86 libs to alleviate this problem with lesstif. Do you recall anything related to this problem? If so, could you describe the fix or point us to a message describing the fix? Thanks in advance, Harold *SIGH* I spoke too soon, after building nedit and trying some other tests, I'm experiencing the "XmManager ClassInitialize: XmeTraitSet failed" problem. Apparently the MacOSX people went through this ordeal last year, but unfortunately that doesn't help us. They had two solutions: 1) Pass "-force_flat_namespace" which is part of OSX's proprietary linker. 2) Downgrade to XFree86-4.1 libs of some sort or upgrade to latest cvs. Of course, in-depth information on why this is happening is nonexistant, all I could find were: http://oroborosx.sourceforge.net/faq.html#q5p1 http://www.geocrawler.com/mail/msg.php3?msg_id=8230372&list=8629 Given that information, I'm willing to bet that an OSX-only fix was checked in sometime after July of last year to resolve this. Finding out what it is will be difficult I'm willing to bet. Of course it could just be Xt misbehaving or an auto-import/psuedo-ops failure. Heh, oh well, I'm going to further investigate this tommorrow... Sorry that it isn't working properly :-(. One last thought, perhaps we should CC Brian Ford in on this since another fresh perspective might be good. Cheers, Nicholas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Michel Dänzer wrote: On Wed, 2003-10-22 at 17:13, Egbert Eich wrote: Marc Aurele La France writes: > > [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I > believe, so is Egbert. No, not currently. I usually go to the web interface and look at the open bugs, process new ones that can be handled quickly, or try to assign them to an expert on the specific area. There are a lot more areas than we have experts - in these cases I try to work on the ticket myself. This, and the low quality of some of the submissions, consumes a considerable amount of time. Indeed, you're doing most of the bugzilla work alone; it's a pity there aren't more people helping with that. Well, you know, XFree86's disregard for offers to help made by developers that have been with the project for over two years are certainly part of the problem. Seriously, I don't know why I waste my time submitting patches that are specific to my platform and then wait up to three weeks for them to be committed. It is a waste of my time and an insult that I am made to do this while other platform maintainers made the luck of the draw and get to commit their patches directly. Here it is: Let me commit my own patches within two months or I am going to let xc/programs/Xserver/hw/xwin die; I will stop sending updates, I will request that you remove hw/xwin and stop advertising that you support Cygwin. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
On Wed, 2003-10-22 at 17:13, Egbert Eich wrote: > Marc Aurele La France writes: > > > > [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I > > believe, so is Egbert. > > No, not currently. I usually go to the web interface and > look at the open bugs, process new ones that can be handled > quickly, or try to assign them to an expert on the specific > area. > > There are a lot more areas than we have experts - in these > cases I try to work on the ticket myself. This, and the > low quality of some of the submissions, consumes a > considerable amount of time. Indeed, you're doing most of the bugzilla work alone; it's a pity there aren't more people helping with that. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
