| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
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.
- Doug
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page