No,
there is no functional changes. I only want to make sure, that no c function
in Intrinsic.c can use the symbol _y (in c 'y'),
so this patch renames it to __$XtInherit, which isn't usable for c
functions.
BTW: I was very in rush while doing the last patch, which may fails to be
applied. The sy
I would be okay with that if it happened. I am the one that recompiled
lesstif and I don't think that the maintainers of other Xt-dependent
apps have recompiled yet.
However, if it isn't a big deal then I will wait until the 4.4.0 release
to make this change. 4.4.0 should be released around D
Errm, this isn't going to change the public interface is it? That is,
if Harold releases another libXt with this change, would that break the
recently re-compiled and released lesstif, etc etc?
--
Chuck
Ralf Habacker wrote:
Not sure I understand. What should be changed in the current version
Harold
>
> Not sure I understand. What should be changed in the current version of
> the Xt code?
only note 1, chaning the label. The second note is only for completeness.
> Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files.
> Please send a diff against these if anything
Ralf,
Not sure I understand. What should be changed in the current version of
the Xt code?
Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files.
Please send a diff against these if anything should be changed. Note
that these are intentionally from the 4.3 branch.
Thanks,
Haro
Harold,
>It looks like you got it nailed to me. I am testing a build right now.
>
I have too additional notes to this patch.
1. Because _Xtinherit is exported as a data symbol, immediate calls to this
function in the manner
...
_XtInherit();
...
will be relocated wrongly and should be a
On Fri, 17 Oct 2003, Ralf Habacker wrote:
> I've found some time to take a look at this problem and it seems as I've got
> a solution, which is documented below.
> Could you please give this a try ?
I had no time to read the patch, but after the latest success messages I have
to thank you for you
Ralf,
It looks like you got it nailed to me. I am testing a build right now.
Harold
Ralf Habacker wrote:
Hi all,
What we would need is a startup function which replaces pointers to the
importlib _XtInherit to the pointer of _XtInherit from the dll.
func reloc_addr[] = { };
unsigned reloc
Hi all,
>
>What we would need is a startup function which replaces pointers to the
>importlib _XtInherit to the pointer of _XtInherit from the dll.
>
>func reloc_addr[] = { };
>unsigned reloc_addr_size = ...;
>__startup_relocate(void) {
>unsigned i;
>func real_func = dlsym("cygXt.dll"
Harold L Hunt II wrote:
> Alexander,
>
> I don't understand how your example code relates to the problem at hand.
the structs x1 and x2 represent widget classes from libXt and from eg xclock.
x1 must be linked into the dll and x2 must be linked into the program.
The other problem is the function
Alexander,
I don't understand how your example code relates to the problem at hand.
I have created a more sophisticated example and I wish that you could
look at it and modify it if it doesn't currently exhibit the problem
either. The code is attached, just 'make' it.
Of course, anyone else
Harold L Hunt II wrote:
> > gcc -shared -o x1.dll x1.c xtinherit.c
> ^^ ^^^
>
> That is the crux of my whole argument, and I believe it is what Alan was
> trying to tell me to do. You do *not* link xtinherit.c/o into x1.dll.
> Instead, only for demonstration pur
Alexander Gottwald wrote:
On Wed, 1 Oct 2003, Harold L Hunt II wrote:
Alexander Gottwald wrote:
Have you tested this with programs which uses libXt and some widgets from
another library?
Yeah, that is what I was saying above. I built a shared version, made
some changes, and rebuilt some clien
On Wed, 1 Oct 2003, Harold L Hunt II wrote:
> Alexander Gottwald wrote:
> >
> > Have you tested this with programs which uses libXt and some widgets from
> > another library?
>
> Yeah, that is what I was saying above. I built a shared version, made
> some changes, and rebuilt some clients (xma
Alexander Gottwald wrote:
On Tue, 30 Sep 2003, Harold L Hunt II wrote:
Error: Unresolved inheritance operation
This error message comes from xc/lib/Xt/Initialize.c/XtInitialize().
This function has been the root of our problems for some time now. IBM
and Sun have ways to work around similar p
On Tue, 30 Sep 2003, Harold L Hunt II wrote:
> Error: Unresolved inheritance operation
>
>
> This error message comes from xc/lib/Xt/Initialize.c/XtInitialize().
> This function has been the root of our problems for some time now. IBM
> and Sun have ways to work around similar problems with X
With the release of Cygwin 1.5.x and newer versions of binutils, can we
finally make libXt a shared library?
I have been working with Alan to try to build a shared version of the
library, but I keep getting the following message upon startup of
Xt-dependent apps:
Error: Unresolved inheritance
17 matches
Mail list logo
