Ulrich Wilkens <m...@uwilkens.de> writes:

> On 06/11/18 04:30, Matthew R. Trower wrote:
>
>>
>> Nah.  The issue is traceable back to Ptr.C and Ptr.h.  Stripping out
>> preprocessor #if noise, the generated entmgr_inst.C tries to do this:
>>
>> ---
>>    template class Ptr<Origin>;
>>    template class ConstPtr<Origin>;
>> ---
>>
>> class Ptr defines and implements a 'clear()' method.
>> class ConstPtr derives from Ptr, and does this:
>>
>> ---
>>    using Ptr<T>::clear;
>> ---
>
>
>>
>> Ulrich, this code compiles fine for you with SunStudio?  It sounds like
>> you've been getting clean builds, yet this is another issue that I've
>> had for years...
>>
>
> Yes, it works for me on 4 systems (OpenIndiana 151a8, Hipster 2014.10,
> Solaris 11.0 and Solaris 11.2). So I can't reproduce your problem.
> But I'm using SolarisStudio 12.3 on all systems.
I'll try to set up an environment with 12.3 tomorrow, and see what
happens.


> I found a similar bug:
>
> https://stackoverflow.com/questions/22233320/is-this-a-mangling-bug-in-solaris-studio
> which seemed to be a compiler problem. Maybe they've fixed it in the
> meantime in newer compilers.
> At least it would be an explanation why it works for me and not for you.

That's a fascinating bug, but shouldn't apply here.  That bug is where
two similar names mangle to the same result (which they shouldn't); here
I have two identical names mangling to the same result (which they
should).  The issue is that they are identical to begin with =(



> I'm also wondering about the paths in your build log:
>   e.g. Current working directory
> /usr/share/src/cde/nsgmls/cde/programs/nsgmls
> Is /usr/share/src/cde/nsgmls/cde your CDE base directory?
> Then I've found for dtksh:
>   /usr/src/cde/nsgmls/cde/programs/dtksh/ksh93/...
> That's another path. Could it be that your CDE installation is a litle bit
> mixed up? Sorry for the question, but this could also cause problems,
> if you are using wrong header files or libraries.

No problem!  Questions can shed light on unexpected problems =)

Yes, that all looks right to me.

/usr/share/src/cde/nsgmls is the CDE repo in this instance.
/usr/src is a symlink to /usr/share/src on OpenSolaris and friends.

so the final build path is either of the following

/usr/share/src/cde/nsgmls/cde
/usr/src/cde/nsgmls/cde



If you're curious how this convoluted path came to be, I have a small
build tool I wrote, which I use on large codebases.  It leverages zfs
snapshots and clones to quickly and cheaply build any arbitrary commit
from a source repo.  It's very useful for building many different
commits in parallel (useful when tracking down a problem, especially on
SPARC hardware with lots of slow threads).  Though, here, I'm just using
it to run some build in the background while continuing to work on
something else in the CDE source tree.

So,
/usr/src/cde is the master folder for CDE repos
/usr/src/cde/nsgmls is the repo clone being built
/usr/src/cde/nsgmls/cde is where you type ~make world~

=)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Reply via email to