Re: configure fails for dar 2.6+ on Solaris

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

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
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl7MJXAACgkQCDGwvQPY
sYIXExAAvq8/aGhYiLMiQNoimbBkWo5XFV9J6rpvIZ1bTT3DkFpiVCktSDPpb2oX
HVZ9P9hoibv/1JCC3pGSChIoc6XSWcO1Q4SJA35yh0MzVk05HdPkbrNIhtHOsbly
9yoQltUP6jPez6UsYmRZjsZ6w56wFUUrnsppBaYi/fy9vu5XyBl+EA0CX4r/bLWt
c7Ky8VSKd82U0q78ieZnZpnzU+buDPxTms8rgvR675kv9T+02go+tgyu9HEyn2kh
nvQz9RJFmVnip43R8MUFZbajAlVCgS+H5LbkAg0sSL5k0Ge3xHuPpmuaOjMbNCtL
dgdzr/fphEXKFrB3JbDUuQOZBpoTiopV2i+yoDX5hfxqtDX24p8AhvA2kZRmQcdY
nN5B+MYuEle8I1nc4w8xSpLNgNty490rDju/qca/9RCjCaT7kZ4AVMchhH0XVVU9
aCtyEzMMzsQJPZM9Y2zS6RnNANPFQ72rLefCKed3mlv97zyuKJQpROpCxpnvWp+p
+HgDuLwdv06fBJjRG+FrjIpEvpCH+qbfVcU3dWXOxbhnj5OcPrONRonNAmlazkjv
FQ5i7NoO3hKZBD9eiXtCFtnjBCBQABAiLR5HXpyls1Lhgt9qkQ9C9NudNPl6ntGi
Ymrx77brPOJPl+UShfzfLdaMWwc5iuWJupmobAyHduNarSFf8Lc=
=8Gli
-----END PGP SIGNATURE-----