Skip to content

Conversation

@sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Nov 18, 2025

The old behavior was to build fake/dummy shared libraries which were really just normal object files. This old behavior can still achieved by settings the new FAKE_DYLIBS settings.

@sbc100 sbc100 marked this pull request as draft November 18, 2025 00:21
@sbc100
Copy link
Collaborator Author

sbc100 commented Nov 18, 2025

@dschuff @kripken not quite ready for review yet but what do you think of this general direction?

The old behavior was to build fake/dummy shared libraries which were
really just normal object files.  This old behavior can still achieved
by settings the new `FAKE_DYLIBS` settings.
@kripken
Copy link
Member

kripken commented Nov 18, 2025

My vague concern is that in practice I recall various build systems used -shared unnecessarily. Ignoring it meant porting was easier (no need to figure out how to remove that link flag from the build system). That might have been just unlucky choices in the things I ported, though - do you have a sense how common the flag is?

@sbc100
Copy link
Collaborator Author

sbc100 commented Nov 18, 2025

My vague concern is that in practice I recall various build systems used -shared unnecessarily. Ignoring it meant porting was easier (no need to figure out how to remove that link flag from the build system). That might have been just unlucky choices in the things I ported, though - do you have a sense how common the flag is?

True, yes, those are exactly the users who would want to start using -sFAKE_DYLIBS.

We could land this with -sFAKE_DYLIBS enabled by default (i.e. we could this essentialy a no-op) for existing users, and then we could propose changing the default as a followup? That would be safer I guess.

@dschuff
Copy link
Member

dschuff commented Nov 18, 2025

Do we currently emit any kind of warning when a user specifies -shared but we ignore it?

@sbc100
Copy link
Collaborator Author

sbc100 commented Nov 18, 2025

Do we currently emit any kind of warning when a user specifies -shared but we ignore it?

yes we have had that for a very long time:

$ emcc hello.c -shared -o libfoo.so
emcc: warning: linking a library with `-shared` will emit a static object file.  This is a form of emulation to support existing build systems.  If you want to build a runtime shared library use the SIDE_MODULE setting. [-Wemcc]

@dschuff
Copy link
Member

dschuff commented Nov 18, 2025

I guess that's good because it raises awareness of the issue, but maybe bad if those folks then just go and add -Wno-emcc and then if we start a deprecation/upcoming behavior change warning they might miss it :)

@sbc100
Copy link
Collaborator Author

sbc100 commented Nov 18, 2025

I guess that's good because it raises awareness of the issue, but maybe bad if those folks then just go and add -Wno-emcc and then if we start a deprecation/upcoming behavior change warning they might miss it :)

Or folks that run cmake the don't read all the warnings.

@sbc100
Copy link
Collaborator Author

sbc100 commented Nov 18, 2025

OK, I'm going to split of the FAKE_DYLIBS setting into a new change that can be landed without changing any existing behaviour.

sbc100 added a commit to sbc100/emscripten that referenced this pull request Nov 19, 2025
This this change the default behaviour does not change since
`FAKE_DYLIBS` defaults to false.

However for users who want to try out a more traditional shared library
workflow `-sFAKE_DYLIBS=0` can be used enable shared library output with
`-shared`.

At some point in the future we can consider making this the default.

Split out from emscripten-core#25817
sbc100 added a commit to sbc100/emscripten that referenced this pull request Nov 19, 2025
This this change the default behaviour does not change since
`FAKE_DYLIBS` defaults to false.

However for users who want to try out a more traditional shared library
workflow `-sFAKE_DYLIBS=0` can be used enable shared library output with
`-shared`.

At some point in the future we can consider making this the default.

Split out from emscripten-core#25817
sbc100 added a commit to sbc100/emscripten that referenced this pull request Nov 20, 2025
This this change the default behaviour does not change since
`FAKE_DYLIBS` defaults to false.

However for users who want to try out a more traditional shared library
workflow `-sFAKE_DYLIBS=0` can be used enable shared library output with
`-shared`.

At some point in the future we can consider making this the default.

Split out from emscripten-core#25817
sbc100 added a commit to sbc100/emscripten that referenced this pull request Nov 20, 2025
This this change the default behaviour does not change since
`FAKE_DYLIBS` defaults to false.

However for users who want to try out a more traditional shared library
workflow `-sFAKE_DYLIBS=0` can be used enable shared library output with
`-shared`.

At some point in the future we can consider making this the default.

Split out from emscripten-core#25817
sbc100 added a commit to sbc100/emscripten that referenced this pull request Nov 20, 2025
This this change the default behaviour does not change since
`FAKE_DYLIBS` defaults to false.

However for users who want to try out a more traditional shared library
workflow `-sFAKE_DYLIBS=0` can be used enable shared library output with
`-shared`.

At some point in the future we can consider making this the default.

Split out from emscripten-core#25817
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.

3 participants