On Thu, Feb 27, 2014 at 2:45 AM, Jon Trulson <j...@radscan.com> wrote:
> On Tue, 25 Feb 2014, Peter Tribble wrote:
>
> On Tue, Feb 25, 2014 at 1:02 AM, <ibid...@gmail.com> wrote:
>>
>> On Mon, Feb 24, 2014 at 09:35:09PM +0000, Peter Tribble wrote:
>>>
>>>> I've been working on getting CDE built on illumos, which should
>>>> also help the various distros derived from OpenSolaris, including
>>>> Solaris 11.
>>>>
>>>> A patch is attached, although this is definitely in the 'works for me'
>>>> category, and probably needs more work. I haven't tested this on
>>>> any other platform. (It seems odd to me that git has included the
>>>> entire file I've deleted, which makes up most of the patch.)
>>>>
>>>>
>>> Glad to hear this.
>>>
>>> I have one question, though: why delete libtt.elist?
>>> When it's deleted, there's no checking the ToolTalk ABI...
>>>
>>>
>> Because the build fails if I don't. Basically, something like this:
>>
>> Undefined first referenced
>> symbol in file
>> _Tt_pat_context_list&_Tt_pat_context_list::append_ordered(const
>> _Tt_pat_context_ptr&) ../../slib/libstt.a(mp_s_pattern.o)
>>
>> looking at the elist file, it's declared private:
>>
>> privateC++ _Tt_pat_context_list::append_ordered(const
>> _Tt_pat_context_ptr&)
>>
>> and likewise for many many more functions. Is there a better way
>> to fix this?
>>
>
> That is interesting... I was not aware that any compilers these days
> looked at files like that... This is the sun studio compiler? Can you
> tell it to ignore elist files?
>
I don't think this is specific to Studio or even Solaris - elist handling
is done on other platforms as well.
The way it works is driven by the rules, which add additional
steps to the link if an elist file is found. Hence the simplest way
for me to fix the build was to remove the file. That's part of the
'works for me' nature of this patch.
I'm digging further into how this is processed, it's a bit of a twisty
maze but I suspect something's also going wrong with C++ name
demangling which is confusing the process.
(This might also explain some of the problems I'm seeing with dtinfo.)
> I won't apply this patch until after 2.2.1 release,
That's *very* sensible ;-)
I would hope to have an improved patch in any case, and it will
probably need to be redone after the recent flurry of other patches.
> but I'd also like
> to understand whether these .elist files are really needed before
> applying this patch.
>
They probably are, but it doesn't look like they're being handled
correctly. (But it's to flush out this sort of query that I sent the
patch along in the first place.)
> There are several other .elist files within CDE that might cause you
> problems.
Indeed. However, none of the others have tripped me up yet.
Still plenty of time for that as there are parts of the tree I haven't
got to.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
