| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On Sun, 2025-10-05 at 22:43 -0500, Bruce Dubbs wrote:
> 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.
Looks like x264 is affected as well (report on #lfs-support).
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page