Question: SHA* symbols being linked into libmysqlclient.a

[treeswift]

Qt build logs (the issue isn't specific to Qt, it's just the first dependent component to encounter it):

lld-link: error: duplicate symbol: SHA224
>>> defined at libmysqlclient.a(my_sha2.cc.obj)
>>> defined at libcrypto.a(sha256.o)

lld-link: error: duplicate symbol: SHA256
>>> defined at libmysqlclient.a(my_sha2.cc.obj)
>>> defined at libcrypto.a(sha256.o)

lld-link: error: duplicate symbol: SHA384
>>> defined at libmysqlclient.a(my_sha2.cc.obj)
>>> defined at libcrypto.a(sha512.o)

lld-link: error: duplicate symbol: SHA512
>>> defined at libmysqlclient.a(my_sha2.cc.obj)
>>> defined at libcrypto.a(sha512.o)

libcrypto.a is a provided by openssl, which is also a dependency of libmysqlclient.

• The obvious pedantic solution would be to move these symbols out of libmysqlclient, amending its dependents if necessary (and if MXE pkg-config has the notion of transitive library dependencies, no amendment will be needed at all).
• A less pedantic solution would be to allow duplicate symbols, but it's another client tweak, and if I have to tweak client packages anyway, I'd rather tweak them the right way.

IOW, the first option is my preference. Objections?

[treeswift]

P.S. Right now only qtbase and gdal use libmysqlclient directly.

[treeswift]

Further looked into it. libmysqlclent builds its own hash implementations. I could move them out of the way by namespacing them or linking libmysqlclient as a DLL rather than statically. (Namespacing is a more local solution; shared linkage, OTOH, would allow us update the mysql revision without rebuilding all the way up.)

[treeswift]

'k, mysqlclient checks for defined(HAVE_OPENSSL), will simply set it.

[treeswift]

Rebuilding w/ -DWITH_SSL=system in libmysqlclient.mk, stay tuned.

[pahaze]

I don't see why mysqlclient is needed TBH... I don't use it in my builds. Does it add more features?

[treeswift]

Check qtbase.mk.
Qt links to a number of database connectors, including MySQL. It's a big umbrella framework. Its advantage, but also its weakness, at times. Many apps can, and do, depend on Qt and nothing else at all, rendering it an important goalpost for me personally.
If we are aiming for a complete distro, I'd rather not strip features unless they come at too large a cost (disk space, effort, or regulatory -- IOW, licensing).

[treeswift]

I am personally aiming for a complete distro. (Suggest a name!)

[pahaze]

Linux?

[pahaze]

Or just in general?

[treeswift]

Linux?

The WinRT kernel is still WinRT kernel, so technically, it's Windows RT (in the same sense both GNU/Linux and Android are Linux).
But application-wise, I want to be able to run everything there is on an average e.g. Ubuntu distro (except kernel modules) on a stock ARM/Tegra Surface RT (32 Gb or 64 Gb) or Surface 2. Basically, make it a usable tablet/mini-laptop.
I already booked a few beta testers (friends' kids).
Going to be the cheapest ARM PC worldwide, until supplies last.)

[treeswift]

("Project 9600" might be a cool name, I just need to check whether MSFT trademarks their build numbers.)

[pahaze]

Ah, I see. I was asking about Linux cause I've wanted to make my own distro for the RT devices. Makes sense, though.

[pahaze]

Oh yeah, if MSFT doesn't trademark then Project 9600 sounds like a good name but what about Win10? Would it be a kinda mix? 😂 Project 9600/15035

[treeswift]

9600 stays the minimum supported version either way. Unless e.g. we find a feature in DX12 that can't be backported to DX11 and that's critical enough to warrant two separate flavors (rather than a runtime-detected flag in a graphic app).
But anyway. Flat Whale? Eclectic Ray? Any other pun on the "surface" theme without using the word "surface"?

[pahaze]

Trying to think of some, not very easy. At school, could ask friends 😂😂😂