Fixup for recent firmware inclusion changes #34
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
jrmithdobbs
commented
Jun 4, 2018
jrmithdobbs
commented
- Minor fix for a bad check that clang (vs gcc) throws a warning for while building.
- Add new msd/*.h and bin2c files to appropriate .gitignore locations.
- Add implementation for fmemopen() for platforms that don't have it.
cleverca22
approved these changes
Dec 17, 2019
bencord0
pushed a commit
to bencord0/rpiboot
that referenced
this pull request
Nov 28, 2020
* Fix check against NULL for a static var actually looking for an empty c string. * Update .gitignore for code change moving msd firmware to static vars. * Fix support for OS X and *BSD after adding static vars for msd firmware.
deepcube
added a commit
to deepcube/usbboot
that referenced
this pull request
Apr 21, 2022
Previously two commits added a fallback fmemopen for OS X/BSD that didn't support fmemopen, then fixed some of the ifdef logic around it. Unforunately the logic was backwards, as libc implementations do not define _POSIX_C_SOURCE in order to advertise features. Instead the user defines _POSIX_C_SOURCE to control which definitions are available. At first glance _POSIX_VERSION could be tested to see if fmemopen is available, but this only solves half the problem. The fallback implementation uses then non-standard BSD specific funopen. This means that even if _POSIX_VERSION is tested, there needs to be a way to test for the existence of funopen. Solve the problem with a short configure script that checks for fmemopen and funopen. This will work independent of which libc and version are used. Fixes: 45c7237 (Fixup for recent firmware inclusion changes (raspberrypi#34)) Fixes: 17f6b01 (Fix cross-platform building)
deepcube
added a commit
to deepcube/usbboot
that referenced
this pull request
Apr 21, 2022
Previously two commits added a fallback fmemopen for OS X/BSD that didn't support fmemopen, then fixed some of the ifdef logic around it. Unforunately the logic was backwards, as libc implementations do not define _POSIX_C_SOURCE in order to advertise features. Instead the user defines _POSIX_C_SOURCE to control which definitions are available. Check _POSIX_VERSION to see if the libc is new enough to implement fmemopen. If it is too old, assume that we're on a BSD compatible system and use the fallback fmemopen that depends on funopen. This solves the problem for some environments, but is still incorrect as it will try to use the fallback even on a system that does not include funopen. Fixes: 45c7237 (Fixup for recent firmware inclusion changes (raspberrypi#34)) Fixes: 17f6b01 (Fix cross-platform building)
deepcube
added a commit
to deepcube/usbboot
that referenced
this pull request
Apr 21, 2022
Previously two commits added a fallback fmemopen for OS X/BSD that didn't support fmemopen, then fixed some of the ifdef logic around it. Unforunately the logic was backwards, as libc implementations do not define _POSIX_C_SOURCE in order to advertise features. Instead the user defines _POSIX_C_SOURCE to control which definitions are available. At first glance _POSIX_VERSION could be tested to see if fmemopen is available, but this only solves half the problem. The fallback implementation uses then non-standard BSD specific funopen. This means that even if _POSIX_VERSION is tested, there needs to be a way to test for the existence of funopen. Solve the problem with a short configure script that checks for fmemopen and funopen. This will work independent of which libc and version are used. Fixes: 45c7237 (Fixup for recent firmware inclusion changes (raspberrypi#34)) Fixes: 17f6b01 (Fix cross-platform building)
pelwell
pushed a commit
that referenced
this pull request
Apr 22, 2022
Previously two commits added a fallback fmemopen for OS X/BSD that didn't support fmemopen, then fixed some of the ifdef logic around it. Unforunately the logic was backwards, as libc implementations do not define _POSIX_C_SOURCE in order to advertise features. Instead the user defines _POSIX_C_SOURCE to control which definitions are available. Check _POSIX_VERSION to see if the libc is new enough to implement fmemopen. If it is too old, assume that we're on a BSD compatible system and use the fallback fmemopen that depends on funopen. This solves the problem for some environments, but is still incorrect as it will try to use the fallback even on a system that does not include funopen. Fixes: 45c7237 (Fixup for recent firmware inclusion changes (#34)) Fixes: 17f6b01 (Fix cross-platform building)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.