Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Harold L Hunt II wrote: 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. I'm working on a similar problem with libXfont. The more I think about it, the more problems I see and I think this is a feature, which ld must provide. The cases where the symbol is undefined in the shared library might get resolved with dispatch functions and code in the program which changes the pointer which is used by the dispatch code. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Torrey Lyons wrote (in a message from Saturday 25) 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. Weak symbols can be used on systems that support them to solve this kind of issues. Does cygwin support them ? If so libXt and libXfont can be patched to provide weak definitions of the SM/ICE functions it needs instead of linking libXt against those libs. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Problems with shared lesstif and shared Xt on Cygwin/XFree86
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=8230372list=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=8230372list=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
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=8230372list=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
