Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IN_LIBXML no longer needed for windows linkage #3475

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

flavorjones
Copy link
Member

@flavorjones flavorjones commented Mar 17, 2025

What problem is this PR intended to solve?

In a comment in #3470, @nwellnhof mentioned his surprise that we were linking with IN_LIBXML on windows.

This change was introduced in 7ace791 as part of the fix for #2167, in which I struggled to get symbols to resolve on Windows.

Note that we also use IN_LIBXSLT and IN_LIBEXSLT as of ba290a4.

Lots has changed in the intervening four years, let's see what happens if I remove it now.

@flavorjones
Copy link
Member Author

Well, apparently we don't need it anymore! 🙌

and the analogous workarounds for libxslt and libexslt
@flavorjones flavorjones force-pushed the flavorjones-remove-in-libxml-define branch from 624a040 to 5046750 Compare March 17, 2025 22:50
@flavorjones flavorjones changed the title wip: testing whether we still need IN_LIBXML for windows linkage IN_LIBXML no longer needed for windows linkage Mar 17, 2025
@nwellnhof
Copy link

This change was introduced in 7ace791 as part of the fix for #2167, in which I struggled to get symbols to resolve on Windows.

Okay, I see. If you want to link libxml2 statically into another Windows DLL and export its symbols, you probably need such a hack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants