Skip to content

Fix creating incorrect .elf file when building .nro - #3

Open
nyanpasu64 wants to merge 1 commit into
fortheusers:mainfrom
nyanpasu64:fix-elf-name
Open

Fix creating incorrect .elf file when building .nro#3
nyanpasu64 wants to merge 1 commit into
fortheusers:mainfrom
nyanpasu64:fix-elf-name

Conversation

@nyanpasu64

Copy link
Copy Markdown

This project's Switch Makefile creates an appname_switch.elf file (from $OUTPUT), then attempts to convert it to appname.nro (from $BINARY). However, it builds appname.nro using libnx's switch_rules pattern, which always builds a %.nro file from an identically-named %.elf file. As a result, make would link a second .elf file named appname.elf, then delete it after converting to appname.nro. As a result, we waste more time and disk space linking twice, and gdb's sharedlibrary (share) command still looks for symbols in the missing appname.elf.

I solved this by writing a custom build rule, which builds appname.nro from appname_switch.elf. If you wanted to use the existing %.nro pattern on appname_switch.elf:

  • You'd have to recursive-make to build appname_switch.nro from appname_switch.elf, then rename the file to appname.nro.
  • You can't add appname_switch.nro as a prerequisite of appname.nro, since if you reran make with no changes, it would see appname_switch.nro is missing, create it again, and rename it on top of the existing appname_switch.nro.
  • If you add an order-only dependency to appname_switch.nro, running make a second time still outputs appname_switch.nro, but doesn't rename it.

Discussion:

  • My understanding is that .elf files are named by platform to avoid different platforms reusing the same names?
  • My suggestion would be to use generic .elf names, place output files in the per-platform build folders, and place intermediate files in a subfolder under that (much like CMake build directories), but this would break current packaging scripts and produce a different directory layout from the standard Atmosphere/libnx/switch-examples makefiles.
  • Why not place the .elf files in build_switch and leave appname.nro at the output root?

The switch_rules .nro pattern requires .nro files to be generated from
an identically-named .elf file. As a result, make would create a second
.elf file with a non-_switch filename, then delete it after converting
to .nro.

I solved this by writing a custom build rule. If you wanted to use the
existing rule on _switch.elf, you'd have to recursively make
_switch.nro, then rename the file to .nro.
@vgmoose

vgmoose commented Jul 8, 2026

Copy link
Copy Markdown
Member

Thanks for this analysis, and yep your understanding is right, without being named per-platform, the wrong arch's appstore.elf would sometimes try to be linked when builds weren't cleaned back to back.

Why not place the .elf files in build_switch and leave appname.nro at the output root?

Is this an option? I haven't made big changes to this Makefile structure since it was introduced, but at the time I remember having a lot of issues fighting with those subfolders and placement of the .elf's

@nyanpasu64

Copy link
Copy Markdown
Author

Why not place the .elf files in build_switch and leave appname.nro at the output root?

Is this an option?

I don't know if it's an option, but don't have the energy to look into it. I also do suspect that gdb may not be able to find the .elf in a subdirectory, unless you launch gdb from it. As a test I tried attaching from the parent of the Git clone, and gdb failed:

(gdb) share
warning: remote target does not support file transfer, attempting to access files from local filesystem.
warning: Could not load shared library symbols for 2 libraries, e.g. appstore_switch.elf.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?

Placing all output files in the build_switch folder would work, but may run into build system design conflicts (I'm not sure).

In any case I don't particularly want to make further changes before this is merged, unless you have an idea of what to change.

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