This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 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: 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




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