crypto: do not create empty.c anymore

[chipitsine]

No description provided.

[botovq]

I am not sure about this. This relies on the fact that all supported platforms will use some compat code for libcrypto, otherwise cmake will be unhappy due to missing object files for libcompat. While this appears to be true based on the CI results and testing this on OpenBSD, I believe at least for OpenBSD this is a bug in the compat code: it detects missing getauxval support - which is correct but not needed - and missing b64_pton - which is incorrect and probably due to naming the symbol __b64_pton, and you need resolv.h to find b64_pton. Rather than removing it outright, I believe we need to handle this correctly in cmake. Presumably we need an empty list of compat files and handle libcompat only if that list isn't empty.

[busterb]

This was originally a workaround to creating static libraries with XCode. See here: #776

Probably worth revisiting the issue.

[chipitsine]

Thanks, I'll check it out

…

On Mon, Feb 12, 2024, 10:45 Brent Cook ***@***.***> wrote: This was originally a workaround to creating static libraries with XCode. See here: #776 <#776> Probably worth revisiting the issue. — Reply to this email directly, view it on GitHub <#996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ5KUAZIGMVRTM6QOA75T3YTHQD7AVCNFSM6AAAAABCTVLCWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZYGMZTGNJWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[chipitsine]

the idea of removing empty.c is to get rid of those warnings

https://github.com/libressl/portable/actions/runs/7869794632/job/21469627057#step:6:29

and once we'll be able to switch windows builds to "all warning are errors"

but there's no rush

[busterb]

Sounds like what we need to do here next is verify if this is still needed for Xcode static builds. If it is, either find another solution, or guard it for that specific case.

[chipitsine]

I plan to try something next weekend

…

On Tue, Feb 27, 2024, 14:05 Brent Cook ***@***.***> wrote: Sounds like what we need to do here next is verify if this is still needed for Xcode static builds. If it is, either find another solution, or guard it for that specific case. — Reply to this email directly, view it on GitHub <#996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ5KUEGWRXJLTPSKWOQ4A3YVXK2HAVCNFSM6AAAAABCTVLCWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRWGUYDKNZYHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[chipitsine]

I reviewed #776
it introduces "dummy.c", changes were reverted lately. currently that file is not used.

I think we can manipulate with empty.c removal without taking that into account.

also, I did not find any repro step how to build "iOS static build with XCode generator", it might be good to add such a build to CI/CD

[chipitsine]

well. there's no rush.
I'll try to find out what is "xcode ios cmake...."

[busterb]

Verified that Xcode still has trouble generating static libraries with the default CMake build if empty.c is removed. Here's what results:

[chipitsine]

I do not own Mac, I can try something on CI using xcodebuild. which steps did you take before building ? пн, 18 мар. 2024 г. в 03:54, Brent Cook ***@***.***>:

…

Verified that Xcode still has trouble generating static libraries with the default CMake build if empty.c is removed. Here's what results: image.png (view on web) <https://github.com/libressl/portable/assets/4108654/492253f0-fb0a-4e28-852f-e6df07c11106> — Reply to this email directly, view it on GitHub <#996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ5KUDHFMKE2UWMCT2MCGDYYZJQDAVCNFSM6AAAAABCTVLCWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSG44DGNBQG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[chipitsine]

as far as I understand, it makes sense to add such "iphone static xcode" builds to CI first to be able to catch regressions

[busterb]

Absolutely. I can submit a PR with this so we can catch it automatically.

…

On Mon, Mar 18, 2024 at 1:03 AM Ilya Shipitsin ***@***.***> wrote: as far as I understand, it makes sense to add such "iphone static xcode" builds to CI first to be able to catch regressions — Reply to this email directly, view it on GitHub <#996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7LC3WBC5QOT7UH62KMUJDYYZ7R5AVCNFSM6AAAAABCTVLCWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSHE4TGNBRGM> . You are receiving this because you commented.Message ID: ***@***.***>

[chipitsine]

nevermind, I've found https://github.com/build-xcframeworks/libressl пн, 18 мар. 2024 г. в 21:49, Brent Cook ***@***.***>:

…

Absolutely. I can submit a PR with this so we can catch it automatically. On Mon, Mar 18, 2024 at 1:03 AM Ilya Shipitsin ***@***.***> wrote: > as far as I understand, it makes sense to add such "iphone static xcode" > builds to CI first to be able to catch regressions > > — > Reply to this email directly, view it on GitHub > <#996 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AA7LC3WBC5QOT7UH62KMUJDYYZ7R5AVCNFSM6AAAAABCTVLCWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSHE4TGNBRGM> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ5KUH5C2IDVCZZRR24B4LYY5HNPAVCNFSM6AAAAABCTVLCWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBUHE3DCMZZG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>