Problems with shared lesstif and shared Xt on Cygwin/XFree86

[Harold L Hunt II]

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
> 
>