Re: configure fails for dar 2.6+ on Solaris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

erratum: this is probably not the compiler that is in cause but the
s_host symbol being #defined for the legacy struct in_addr (internet
socket)... I will see how to avoid this conflict tomorrow.

On 25/05/2020 22:07, Denis Corbin wrote:
> Hi,
> 
> In complement to Mihai response, I've installed omniOS in a VM, 
> upgraded the system to the latest version (5.11) and installed
> some dev packages (pkg install "developer/*"), then cloned the dar
> github repository, checkout branch_2.6.x, and run misc/init without
> problem. I also tested the master branch and could build the
> configure script without problem with misc/init.
> 
> I then ran "make" and got an strange error while compiling: the
> compiler complains against an classical enum datastructure (!) used
> in src/dar_suite/line_tools.cpp
> 
> After some testing, replacing the symbol "s_host" of this
> enumeration by some other (like "xs_host") fixes the compilation
> issue (!) I got a usuable dar binary.
> 
> I could not find any official information about such "s_host"
> symbol as being reserved in C nor C++. Worse, if I use an "enum
> class" which wraps the listed symbols into a separated namespace,
> the problem persists with this s_host symbol still breaking
> compilation!
> 
> It seems to me that the compiler used in this system [g++ (OmniOS 
> 151034/9.3.0-il-1) 9.3.0] has a internal leaking symbol that
> conflicts with the code under compilation... or some other ugly
> issue... unless someone can find any official info about the fact a
> C or C++ program should not use the "s_host" symbol. Let me know,
> if so.
> 
> Regards, Denis
> 
> On 25/05/2020 13:21, Mihai Moldovan wrote:
>> * On 5/25/20 1:10 PM, Blandon Ray wrote:
>>> I did run misc/init to generate the configure script, yes. And 
>>> each time I pulled a completely clean tree. I was hoping to
>>> look carefully at what is different about the working 2.5
>>> version but trying to compare them side by side did not produce
>>> anything instructive.
> 
>> Since the configure script is auto-generated and will be
>> different based on the used toolchain, I guess we can't help
>> without seeing it.
> 
>> The line number is usually a pointer, but quite often for some 
>> reason doesn't seem to match the actual fail location. That's 
>> another thing to take into account.
> 
>> configure.ac has seen quite a bit of changes from 2.5.22 to
>> 2.6.0. Can you additionally make sure that the v2.6.0 tag fails
>> in the same manner?
> 
> 
> 
>> Mihai
> 
> 
> 
> 
>> _______________________________________________ Dar-support
>> mailing list [email protected] 
>> https://lists.sourceforge.net/lists/listinfo/dar-support
> 
> 
> 
> _______________________________________________ Dar-support mailing
> list [email protected] 
> https://lists.sourceforge.net/lists/listinfo/dar-support
> 
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl7MKBMACgkQCDGwvQPY
sYKLPhAAvM8ZOsFwPfqFTGsF2GjofuFPztmekXB+bg6LuzPUwG34SLtFiephzL+8
e594VJkWuFKwtevyO+aGNOwHziVaDhm87Yoi1d1tiwk/nhMyqr4nl8kSOERVcN1x
9GXbQfxTUeegClOKx0xAHgC/UNivEuKgTxNOUHeTVY6P6aVhDeK4WEdZlN8xcWIu
E06OFjmS9fqoUUQPtuDKUChGycw4YcVWGIADA9J8XbCK8Vy9fUyxjg0S0OwGaBJV
uJbjC58t20JSzhPdEzqzDbMd6jqy4Oav+ZTJMhbguz/ckcv9EtVwtqZrKkIph77V
z07dmSo9zl6QDrlZXARuCEovRV7s2p3H8UtIWjGIl1bBHuehaysTcm3z/7I20wch
j16fJM9+lUyyMsSBCiBgHSn1o/p8/ZBGmGDwlhqawvK73kOcKxFwoetVsET46LuY
wNi3rsPFKW8MvYsI5/v84cyYOWES6kNUCCVadZ2+MffMxVrcXYQxpyrbkw1qXWKa
bs9wAhH79PdDD3QRU6eLoLH/ekPGRX/NGex3t7X3wpeC6I7jb+erHA5rFrjjCPLj
QYB02revGD/2XEvrJkCcaW/K1Cc2PF4ATxG2wJ8K/oJkvpjRycVaBFplf5f+nFk9
3hX7huWKjqtgx9ID7+zwjiBTCYPCWKgPNX7soUds8d6/+T4Tj3M=
=VASQ
-----END PGP SIGNATURE-----