| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On 10/5/25 8:10 PM, "Douglas R. Reno" ([email protected] via blfs-dev
Mailing List) wrote:
> On 10/5/25 6:34 PM, Zeckma ([email protected] via blfs-dev Mailing List) wrote:
>> Hello everyone.
>>
>> We have a problem with NASM-3.00. It is currently in the development
>> books of BLFS. 3.00 made changes that affects packages like dav1d and
>> libaom. I haven't tried packages besides those, but the scope may be
>> bigger, I don't know quite yet.
>>
>> For dav1d, the assembly files have operands in an order that NASM-3.00
>> forced to be the other way according to the specification. This causes
>> dav1d to fail to build from source.
>>
>> In libaom's case, it fails to even configure via CMake as the NASM is
>> unsupported. This is because the build system uses NASM's help output,
>> in which it was changed. It expects all the supported options and build
>> targets to be shown with the current options -hf. The problem is now
>> the options it wants to see plus the build targets have been split up.
>> Now, it would want -h0 plus -hf, which cannot be ran in the same
>> command.
>>
>> Lack of energy and time, I see it as a good idea to simply downgrade
>> NASM to 2.x.x until these issues in other packages have been fixed.
>>
>> Apologies to anyone who installed NASM-3.00 as a result of it being in
>> the development books. I heavily recommend to downgrade to NASM-2.16.03
>> to prevent build failures.
>>
>> - Zeckma
>>
> I'm in favor of it myself, but my reasons are mostly related to a general lack of
> energy and time. Working on the book takes a lot, and it's especially frustrating
> when we're having several things cause breakages within a short period of time, and
> we have to chase down upstreams to get them resolved. The occasional breakage isn't a
> problem, but so far we have had these issues with nasm-3, we've had problems due to
> ffmpeg-8, and we also currently have problems with Poppler that I need to resolve -
> just in the last month! Last cycle, it was problems with libxml2, GCC, CMake 4.x, and
> glib/gobject-introspection (especially when combined with libpeas).
>
> Right now, I am also trying to build a SysV system so I can take care of GNOME 49 and
> some of the changes that come with that for SysV systems. If I need to spend a bunch
> of time chasing down problems with this package, it could take me quite a long time
> to get there (and also resolve the security issues in WebKitGTK, because I will need
> to update some GNOME components to get to Epiphany). This breaks at least libaom and
> dav1d so far, which we will now need to collaborate with upstream to fix (if there
> aren't fixes already), just so I can build libavif.
>
> A temporary solution in my case would be to just downgrade to NASM-2.16.03, but
> because these are development systems, it doesn't make sense for me to do so. What's
> on my system should be a carbon copy of what's in the book.
>
> This means also that if a package that uses NASM-3 is broken, and we get a security
> update for it, we could be unable to act on it until upstream resolves the issues.
> The same applies to other packages where major changes are made of course though, but
> in this case it could impact LAME, Thunderbird, Firefox, Seamonkey, Libreoffice, gst-
> plugins-good, ffmpeg, libvpx, x264, x265, xvid, libass, sdl2, libjpeg-turbo, and svt-
> av1.
>
> For now it might be best to wait and see what happens with upstreams and just try to
> note the issues, but it makes it really tedious to build a system to investigate
> things (like what I'm doing with GNOME), especially because I will now encounter at
> least two packages which will not build, and both of them are needed for a security
> update that I need to do.
Let's give it a week to see if upstream makes the needed fixes. Most of the packages
that use nasm are in multimedia and mozilla. I see 21 references to nasm in the book
but not all of them are broken. For instance lame and sdl2 and ffmpeg are OK.
-- Bruce
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page