https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
--- Comment #9 from Cameron ---
(In reply to Martin Neubauer from comment #8)
Still fails with the same issue with this patch. I tried the same fix by adding
the line manually to the Makefile last week and it failed then too so this
isn't
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
--- Comment #8 from Martin Neubauer ---
(In reply to Cameron from comment #6)
As I commented earlier, #277021 is is a different issue altogether. I just
added a patch with the workaround from the original bug description to
hopefully cut
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Martin Neubauer changed:
What|Removed |Added
Attachment #248901||maintainer-approval?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
--- Comment #6 from Cameron ---
Tried the patch from #277021
It did not fix the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Martin Neubauer changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
--- Comment #5 from Anton Saietskii ---
Created attachment 248893
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248893=edit
poudriere build failure log
(In reply to Martin Neubauer from comment #0)
Same here with releng/13.3,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226919
Charlie Li changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277368
Charlie Li changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Cameron changed:
What|Removed |Added
CC||c...@neo-zeon.de
--- Comment #4 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277368
Vladimir Druzenko changed:
What|Removed |Added
CC||v...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277368
gebh...@secnetix.de changed:
What|Removed |Added
CC||gebh...@secnetix.de
---
Bugzilla Automation has asked freebsd-gecko (Nobody)
for maintainer-feedback:
Bug 277368: www/firefox 123.0 incorrectly speciffies Linux as OS instead of
FreeBSD in the User Agent string
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277368
--- Description ---
It's not a severe bug, but
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277368
Bug ID: 277368
Summary: www/firefox 123.0 incorrectly speciffies Linux as OS
instead of FreeBSD in the User Agent string
Product: Ports & Packages
Version: Latest
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261898
Geometry Dash apk changed:
What|Removed |Added
CC||zeeshanwrit...@gmail.com
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Benjamin Jacobs changed:
What|Removed |Added
CC||free...@dev.thsi.be
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277159
Lars Herschke changed:
What|Removed |Added
Attachment #248597|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277159
Bug ID: 277159
Summary: www/firefox-esr: fix for the about:support page
Product: Ports & Packages
Version: Latest
Hardware: Any
OS: Any
Status: New
Bugzilla Automation has asked freebsd-gecko (Nobody)
for maintainer-feedback:
Bug 277159: www/firefox-esr: fix for the about:support page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277159
--- Description ---
Import patch patch-toolkit_components_processtools_procinfo__bsd.c from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #75 from Tatsuki Makino ---
(In reply to jakub_lach from comment #74)
> I've wrote in comment #53
Yeah, you got 磊 I got 賂 or 雷 on 䔪 or nothing 藍
But this can only be a workaround-patch, and we will need a fix-patch.
It seems
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #74 from jakub_l...@mailplus.pl ---
(In reply to Tatsuki Makino from comment #70)
> This seems to be an SSE4 instruction, so CFLAGS+=-mno-sse4 is the minimal
> workaround.
> Could this time be the basis for a correct patch? :)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #73 from Tomoaki AOKI ---
(In reply to Tatsuki Makino from comment #70)
Interesting. But resulting assembly codes seems to be reverse with what
happened.
For "-march=" case, libm should be surely needed, while
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #72 from Nuno Teixeira ---
(In reply to Tatsuki Makino from comment #70)
> This seems to be an SSE4 instruction, so CFLAGS+=-mno-sse4 is the
> minimal workaround.
How could that affect aarch64 like I'm experience on rpi4?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #71 from Nuno Teixeira ---
(In reply to Nuno Teixeira from comment #67)
> Status: aarch64 (rpi4)
> - main and poudriere jail @ 3733d82c4deb
> - build from a cleaned pkgs poudriere
> - `pkg delete -af` && install pkgs
>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #70 from Tatsuki Makino ---
(In reply to Tomoaki AOKI from comment #69)
> I cannot understand why CPUTYPE causes ceil() and floor() is used or not.
Me too :)
There is no reason for this anywhere in the Firefox source code.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #69 from Tomoaki AOKI ---
(In reply to Tatsuki Makino from comment #68)
I cannot understand why CPUTYPE causes ceil() and floor() is used or not.
Just a possibility, for slow and old CPUTYPEs, firefox has alternative, maybe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #68 from Tatsuki Makino ---
(In reply to Tomoaki AOKI from comment #66)
Perhaps so.
Looking a little more closely, first, the commands to which
/usr/local/lib/firefox/firefox is linked are as follows.
All seemingly unimportant
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277121
Jan Beich changed:
What|Removed |Added
Assignee|jbe...@freebsd.org |ge...@freebsd.org
CC|
Jan Beich has asked freebsd-gecko (Nobody)
for maintainer-feedback:
Bug 277121: www/firefox: fails to build on /quarterly (2024Q1) due to libvpx <
1.14.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277121
--- Comment #1 from Jan Beich ---
ports 7659a22057ab forced libvpx 1.14.0 despite
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #67 from Nuno Teixeira ---
Status: aarch64 (rpi4)
- main and poudriere jail @ 3733d82c4deb
- build from a cleaned pkgs poudriere
- `pkg delete -af` && install pkgs
`firefox`: same error as mentioned.
Rebuilding only firefox
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #66 from Tomoaki AOKI ---
(In reply to Tatsuki Makino from comment #65)
According to math(3) manpage, lines including and below atan seems to be belong
to libm. So libm shoule be required regardless dropped lines for blank
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #65 from Tatsuki Makino ---
(In reply to Tomoaki AOKI from comment #64)
Hmmm, I don't know :)
It seems to me that if we replace the y=x/60;z=x%60; calculation with div,
Intel's CPU reduces the division from twice to once.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #64 from Tomoaki AOKI ---
(In reply to Tatsuki Makino from comment #63)
Can simd(7) affect?
https://man.freebsd.org/cgi/man.cgi?query=simd=0=0=FreeBSD+15.0-CURRENT=default=html
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #63 from Tatsuki Makino ---
(In reply to Ale from comment #62)
A change here could be used as one of the workarounds, but it is not a
fundamental solution.
Because the presence or absence of -march changes whether
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #62 from Ale ---
(In reply to Tatsuki Makino from comment #61)
Interesting.
Maybe dependentlibs.list is read at start to open dependent library files.
As you said in comment #60 moving libmozgtk.so before libgkcodecs.so works,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #61 from Tatsuki Makino ---
(In reply to Tatsuki Makino from comment #60)
It seems that /usr/local/lib/firefox/dependentlibs.list is genelated by
${WRKSRC}/toolkit/library/build/dependentlibs.py.
According to the py script,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Tatsuki Makino changed:
What|Removed |Added
CC||tatsuki_mak...@hotmail.com
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #59 from jakub_l...@mailplus.pl ---
(In reply to fgorter from comment #58)
Have you checked if the (problematic) built have pulled in libm and/or tried
preloading library as above?
I don't think that ports tree can get
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Martin Neubauer changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Martin Neubauer changed:
What|Removed |Added
See Also|https://bugs.freebsd.org/bu |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
fgorter changed:
What|Removed |Added
CC||fgor...@gmail.com
--- Comment #58 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #57 from Tomoaki AOKI ---
Forgot to mention.
Currently, not sure why, cgit.freebsd.org is not responsive.
I've searched the commit logs using local `git log HEAD` (PAGER is lv).
So no cgit links are listed, although I usually
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #56 from Tomoaki AOKI ---
If toolchains used is affecting, new questions arises.
*What version affecting with this?
As firefox wants wasi-* components for WebAssembly and wasi-* must be
in sync with llvm used, base
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #55 from jakub_l...@mailplus.pl ---
(In reply to Ale from comment #54)
and 3) only some CPUTYPEs are affected (see comment #53)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #54 from Ale ---
(In reply to Guido Falsi from comment #52)
I was telling that since comment #11!
After a running build with all entries commented in make.conf (I was suspecting
CFLAGS, or maybe CCACHE) resulting in a running
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Vladimir Druzenko changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Vladimir Druzenko changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
Bug ID: 277075
Summary: www/firefox: build failure on 14-STABLE
Product: Ports & Packages
Version: Latest
Hardware: Any
OS: Any
Status: New
Bugzilla Automation has asked freebsd-gecko (Nobody)
for maintainer-feedback:
Bug 277075: www/firefox: build failure on 14-STABLE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277075
--- Description ---
After the update to version 123 www/firefox startedhaving build failures. The
relevant
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #53 from jakub_l...@mailplus.pl ---
(In reply to Vladimir Druzenko from comment #18)
That's actually interesting, as only difference between core2 and penryn (not
working here) should be +sse4.1. I assume cputypes after penryn
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #52 from Guido Falsi ---
I made a test and compiled firefox without any CPUTYPE set. no -mcpu or -march
flags passed to the compiler (according to build logs).
And it now works fine, without linking to libm.
So at this point
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #51 from Guido Falsi ---
(In reply to Vladimir Druzenko from comment #50)
I'm not planning on doing it, I was just "brianstorming".
This is not an easy thing to fix.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #50 from Vladimir Druzenko ---
(In reply to Guido Falsi from comment #49)
> Maybe disabling CPUTYPE in the firefox port in some way? (not sure hot to do
> that, though)
No, plz, it work fine for me with CPUTYPE?=core2.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #49 from Guido Falsi ---
(In reply to jakub_lach from comment #45)
Interesting find, although that's an old issue actually. I'd hope it had been
solved for good by now.
Anyway this makes it possible this depends on CPUTYPE, I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #48 from Tomoaki AOKI ---
(In reply to jakub_lach from comment #47)
Yes, if CPUTYPE is defined with CPUTYPE= somewhere else in the build chain.
But IIUC, there's none for building firefox.
Note that this conditional is for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #47 from jakub_l...@mailplus.pl ---
(In reply to Tomoaki AOKI from comment #46)
If you have
if !${.CURDIR:M/usr/src/sys/boot*}
CPUTYPE?= haswell
endif
that does not mean it necessarily uses haswell for firefox (see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #46 from Tomoaki AOKI ---
OK. I already have working (patched) pkg of firefox. So backing up the pkg,
backed out the patch and rebuilt firefox.
The rebuilt one didn't start, while restoring patched one fixed the issue.
Broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #45 from jakub_l...@mailplus.pl ---
(In reply to Vladimir Druzenko from comment #18)
Overall from this PR I have strong suspicion that only some cputypes
optimizations might use (need) libm, compare -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #44 from Ale ---
(In reply to Nuno Teixeira from comment #36)
I have the same output for ldd and a running firefox on amd64 stable/13
(13.3-STABLE) building it without CPUTYPE in make.conf.
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #43 from Tomoaki AOKI ---
(In reply to Guido Falsi from comment #42)
Another possibility is that "what GPU (driver) is used" is affecting.
And using X or Wayland (possibly with xwayland).
These could affect indirectly and does
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #42 from Guido Falsi ---
(In reply to jakub_lach from comment #41)
Ok, but, this is the same as adding LDFLAGS to the port Makefile.
What needs to be ascertained before an action can be taken in the ports tree is
why some
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #41 from jakub_l...@mailplus.pl ---
(In reply to Guido Falsi from comment #34)
I've fixed my problem without patch, by adding
if ${.CURDIR:M*/www/firefox}
LDFLAGS+= -lm
endif
to make.conf (ports.conf)
$ ldd -a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #40 from Nuno Teixeira ---
(In reply to Guido Falsi from comment #37)
Default options on all ports included firefox.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #39 from Tomoaki AOKI ---
(In reply to Nuno Teixeira from comment #36)
Not likely.
As libsys is , IIUC, basically syscall portion of libc splitted out and treated
as filtee, keeping filter in libc and at least libthr.
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #38 from Tomoaki AOKI ---
(In reply to Guido Falsi from comment #34)
Thanks! Built and running fine with your patch. stable/14, amd64.
Note that as I haven't built firefox without any of fixes, not sure firefox
without fix
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #37 from Guido Falsi ---
(In reply to Nuno Teixeira from comment #36)
I have no real explanation for that.
Maybe it depends on options in some other (multimedia presumably) port,
although that should show up in ldd output.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #36 from Nuno Teixeira ---
(In reply to Ale from comment #35)
That must be something happening:
On my current-4594eb454891 amd64 I have firefox 123.0_1,2 running ok and no
libm on ldd:
ldd -a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #35 from Ale ---
(In reply to Guido Falsi from comment #34)
I built 123.0 (rc3) and the problem still exists.
Building it again with "tentative patch v1" fixed the problem.
$ ldd -a /usr/local/lib/firefox/libgkcodecs.so
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #34 from Guido Falsi ---
Created attachment 248472
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248472=edit
tentative patch v1
I created a patch, based on suggestions here, to ease review/merging.
I think
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #33 from Tomoaki AOKI ---
Found below within official ports patch as [1].
Which expression is correct? "lm"? "-lm"? or "m"?
Or all workes samely?
I'm confused now.
--- third_party/sqlite3/src/moz.build.old 2021-08-09
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #32 from Stefan Ehmann ---
(In reply to Jesper Schmitz Mouridsen from comment #30)
Adding OS_LIBS += ["-lm"] fixed the problem for me on 14.0/amd64. I have
CPUTYPE set in make.conf
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #31 from Guido Falsi ---
(In reply to Jesper Schmitz Mouridsen from comment #30)
I was thinking about something along these lines, but I have no idea if this is
the correct solution.
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Jesper Schmitz Mouridsen changed:
What|Removed |Added
CC||j...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #29 from Guido Falsi ---
(In reply to Guido Falsi from comment #28)
Maybe the right place to look at is `toolkit/library/moz.build`
But I really don't know. Someone that has at least an idea of how firefox build
system works
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #28 from Guido Falsi ---
Having a look at firefox sources I found something interesting in
`third_party/libwebrtc/moz-patch-stack/0106.patch`:
--
From: Chun-Min Chang
Date: Tue, 5 Dec 2023 20:08:00 +
Subject: Bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #27 from Guido Falsi ---
The fact that libm.so is not showing in both outputs tells me there is no way
the -lm option was passed to the linker at build time.
But I have no idea how to firefox build system works, so I'm not
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #26 from jakub_l...@mailplus.pl ---
(In reply to Nuno Teixeira from comment #25)
$ ldd -a /usr/local/lib/firefox/libgkcodecs.so
/usr/local/lib/firefox/libgkcodecs.so:
libthr.so.3 => /lib/libthr.so.3 (0x299200289000)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #25 from Nuno Teixeira ---
(In reply to Guido Falsi from comment #24)
ldd -a /usr/local/lib/firefox/libgkcodecs.so
/usr/local/lib/firefox/libgkcodecs.so:
libthr.so.3 => /lib/libthr.so.3 (0xa324f6e6000)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #24 from Guido Falsi ---
(In reply to Tomoaki AOKI from comment #22)
I don't think that can be possible. The failure happens during startup, while
ld is doing the dynamic linking. Not even a single line of code from firefox
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #23 from Ale ---
Has anyone else with the same problem + CPUTYPE... in /etc/make.conf tried to
rebuild the port after commenting the CPUTYPE... line?
For me that solved the problem.
Searching for "-lm" in the configure output
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #22 from Tomoaki AOKI ---
(In reply to Lars Henrik Ørn from comment #21)
I didn't mean "build options", but something with "about:config" and/or
settings menu.
These can be changed at run time (some would require restarting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #21 from Lars Henrik Ørn ---
(In reply to Tomoaki AOKI from comment #20)
As you can see above, some of did rebuild yesterday with different options.
Without success. So that is afaik no the problem
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #20 from Tomoaki AOKI ---
As firefox is a complexed software, is there any possibility that this problem
depends on profiles? Means that if some specific options are enabled
(regardless it's the defaut or not), libm is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #19 from Guido Falsi ---
(In reply to Vladimir Druzenko from comment #18)
I have an hunch this is triggered by something in the order in which
ports/packages have been built/installed/updated (or not updated by poudriere).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Vladimir Druzenko changed:
What|Removed |Added
Summary|www/firefox: error on start |www/firefox: error on start
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #18 from Vladimir Druzenko ---
But it work fine on 13.2 with CPUTYPE?=core2.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #17 from Nuno Teixeira ---
(In reply to Guido Falsi from comment #16)
> I also noticed this line in firefox configure output:
> js/src> checking for sin in -lm... yes
I see same check on my log where firefox is affected.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #16 from Guido Falsi ---
(In reply to Stefan Ehmann from comment #9)
> "Looks like a missing -lm to me." was mentioned on the ports mailing list.
That was me :)
I'm also experiencing this on amd64, using head from a few
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Tomoaki AOKI changed:
What|Removed |Added
CC||junch...@dec.sakura.ne.jp
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #14 from jakub_l...@mailplus.pl ---
(In reply to Ale from comment #11)
Yes, I have CPUTYPE?=penryn among other port specific things (amd64).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #13 from Lars Henrik Ørn ---
Yes. I have set CPUTYPE to alderlake. And to me that is the whole point of
building packages. Together with a few flags for packages. It makes my system
quite a lot snappier than otherwise.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Nuno Teixeira changed:
What|Removed |Added
CC||edua...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #11 from Ale ---
(In reply to Stefan Ehmann from comment #9)
I was thinking the same about the missing -lm.
I think that some stuff in /etc/make.conf could be messing the compiler flags
order for this version, or something like
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #10 from jakub_l...@mailplus.pl ---
(In reply to Stefan Ehmann from comment #9)
Makes sense, thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
Stefan Ehmann changed:
What|Removed |Added
CC||shoes...@gmx.net
--- Comment #9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
jakub_l...@mailplus.pl changed:
What|Removed |Added
CC||jakub_l...@mailplus.pl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #7 from Ale ---
I'm getting the same error with rc2 (firefox-123.0_1,2).
$ make showconfig -C /usr/ports/www/firefox
===> The following configuration options are available for firefox-123.0_1,2:
CANBERRA=off: Sound theme
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #6 from Lars Henrik Ørn ---
I am on 14 STABLE.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #5 from Vladimir Druzenko ---
13.2 - llvm 14
13.3 - llvm 17
13-STABLE - llvm 17
14.0 - llvm 16
14-STABLE - llvm 17
Do you have 13.2 and/or 14.0 for test?
Or maybe you can build firefox for 13.2 and run on your current system?
101 - 200 of 6065 matches
Mail list logo
