Skip to content

musl: backward compatibility with 64-bit definitions#12667

Draft
oskarirauta wants to merge 1 commit intoopenwrt:mainfrom
oskarirauta:musl-compat
Draft

musl: backward compatibility with 64-bit definitions#12667
oskarirauta wants to merge 1 commit intoopenwrt:mainfrom
oskarirauta:musl-compat

Conversation

@oskarirauta
Copy link
Contributor

added as a draft - if you are working with fixing problems related to recent musl update, this patch
will hide all those problems and then this is not for you - but if you work with something else, and just have
to get most of openwrt compiled, this will give you a huge head start. Also with this, problems with building rust for example - are avoided. Merging this patch to openwrt mainstream probably isn't the way wanted - I am not sure if it's the plan on alpinelinux on long term either- but for now, this is useful to get your os built.

patches musl 1.2.4 to backwards compatible with missing/removed/deprecated/obsolete 64-bit definitions, such as dirent64 or lseek64.

Patch set origin is from alpine linux.

patches came from https://git.alpinelinux.org/aports/tree/main/musl?h=master one of them didn't patch without issues, so I worked it out and modified content is on patch 998.

patches musl 1.2.4 to backwards compatible with missing/removed/deprecated/obsolete
64-bit definitions, such as dirent64 or lseek64.

Patch set origin is from alpine linux.

patches came from https://git.alpinelinux.org/aports/tree/main/musl?h=master
one of them didn't patch without issues, so I worked it out and modified
content is on patch 998.

Signed-off-by: Oskari Rauta <oskari.rauta@gmail.com>
@github-actions github-actions bot added the toolchain pull request/issue with toolchain related changes label May 19, 2023
@ptpt52
Copy link
Contributor

ptpt52 commented May 19, 2023

looks great.

@ptpt52
Copy link
Contributor

ptpt52 commented May 20, 2023

I wonder why 64-bit definitions is missing after musl 1.2.4? those 64-bit definitions is deprecated/obsolete so they were dropped?

@oskarirauta
Copy link
Contributor Author

@ptpt52
I'm glad if you found it useful.

64-bit definitions are not missing, it's more like that 32-bit definitions are.
dirent = dirent64

Meaning that they obsoleted 32-bit versions for 64-bit systems, and renamed 64-bit definitions to what used to be 32-bit. So that, if your system is 32-bit, struct dirent is 32-bit, but if 64-bit, it's 64-bit; definition name just remains the same but whether it is 32-bit or 64-bit, is system dependant, except for off_t which always has been 64-bit but used to have 64-bit alias as well.

Defining GNU_SOURCE with -D when building used to be sufficient, but now you need to define LARGEFILE support as well, to get compatibility with "past" version- but in some cases this isn't enough, for example, with rust which I mentioned. It's under work in progress to get rust to support this, but it will be a slow process (in about month while writing this, if they get it done in time/on that update).

Why they did this? Without further investigation I would say that 32-bit systems are getting old... So maybe it then is that they wanted more unified code? Things just happen sometimes and it's a bummer for some people, has happened for a long time- whether it was libc/equillavent, Mac OS X or Windows, sometimes something is lost even if you see no point in that. For example, in my case, I used to use a calculator widget in my OS X's, it was actually the only widget I used, I do not read news or stock changes from there - but it was a quick access to calculator; but few years ago, they re-designed it - and while at it, calculator was lost, for good.

@oskarirauta
Copy link
Contributor Author

This could be merged, but I suspect that it would just delay what is ahead. I made this PR only as a draft to save some trouble from others.

@zxlhhyccc
Copy link
Contributor

could be merged

Yes,could be merged.

@nekopsykose
Copy link

Meaning that they obsoleted 32-bit versions for 64-bit systems, and renamed 64-bit definitions to what used to be 32-bit. So that, if your system is 32-bit, struct dirent is 32-bit, but if 64-bit, it's 64-bit; definition name just remains the same but whether it is 32-bit or 64-bit, is system dependant, except for off_t which always has been 64-bit but used to have 64-bit alias as well.

this isn't correct; musl never had the 32-bit versions of this api. struct dirent for instance differs in whether ino_t is 32-bit or 64-bit, which is where the lfs64 naming comes from. on musl, all of this was always 64-bit with any name, the *64 names were just lfs compatibility aliases. on 32 or 64 bit systems you always got 64-bit largefile support regardless of what the program tried to call.

in a similar unrelated vein, since 1.2.x (not since inception) time_t went the same way- it's always 64.

originally, 64-compat was added 11 years ago in 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c. they were always macros :)

@oskarirauta
Copy link
Contributor Author

@zxlhhyccc yes. Alpine went that way. But I wouldn't be that sure if it's permanent...

@nekopsykose I trust your word better than my own on this :)

@zxlhhyccc
Copy link
Contributor

@zxlhhyccc yes. Alpine went that way. But I wouldn't be that sure if it's permanent...

Whether it is permanent is to be dealt with later。The current issue to address is rust's failure to compile other source code。

@oskarirauta
Copy link
Contributor Author

@zxlhhyccc you got a point there, but - I can't talk on behalf of the staff - I am just a random contributor, I think - were alpine is on the edge of development (on edge version), openwrt's development plan has a different path. But for sure, this can be reviewed and merged, but that to be considered, you would need to invite people that do belong to staff. That way you also get the answer, without members with access to merging rights- I won't change this from draft to reviewable as I do not wish to bother them, when I am pretty sure that this isn't the way how important members want this to go. But since I just had to have rust working, I made this - and didn't want people need to re-invent the wheel, I made it available for everyone to save them from trouble.

@oskarirauta
Copy link
Contributor Author

oskarirauta commented Sep 18, 2023

This is not necessary anymore, so I am closing this.

EDIT: unless you need rust... still no musl 1.2.4 support available.

@oskarirauta oskarirauta reopened this Sep 20, 2023
oskarirauta added a commit to oskarirauta/openwrt-rust that referenced this pull request Oct 9, 2023
It also does not need openwrt/openwrt#12667 anymore
with patch from gentoo.

Signed-off-by: Oskari Rauta <oskari.rauta@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

toolchain pull request/issue with toolchain related changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants