Re: replacement for xmms?
Jack L. writes: > I'd love to keep xmms but it seems gtk1 was removed from ports in > the latest FreeBSD ports release so running xmms became > problematic. I guess after 20 years of using xmms, it was time to > move onto something of this decade Twenty four hours into using Audacious ... it looks like a good replacement. Mind you, my requirements are pretty minimal. Respectfully, Robert Huff ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: replacement for xmms?
I'd love to keep xmms but it seems gtk1 was removed from ports in the latest FreeBSD ports release so running xmms became problematic. I guess after 20 years of using xmms, it was time to move onto something of this decade On Thu, Jan 17, 2019 at 2:16 AM Samy Mahmoudi wrote: > > xmms was so great ! I still use it and even managed to build a pulseaudio > plugin last year, as I needed to be able to switch between outputs while > playing (can OSS do that ?). > > Why do you need a replacement for xmms ? I have personally noticed some > minor problems with xmms: > • old-style GTK+ menu > • accented characters don't display correctly > • while xmms is running, I can't easily switch between virtual desktops > (xfce4 + compiz) > • audio format compatibility (still pretty large with plugins) > > I will have a look at the recently deprecated x11/gtk-theme-switch and the > gtkrc file for the first two problems, although looking for a modern > alternative is probably the best way to go. > > Le jeu. 17 janv. 2019 à 01:27, Robert Huff a écrit : > > > > > I'm looking for something not too complicated, that runs in a > > GUI. > > Suggestions? > > > > > > Respectfully, > > > > > > Robert Huff > > > > ___ > > freebsd-ports@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Separate build/runtime llvm60 dependencies
Niclas Zeising writes:
> On 1/17/19 12:17 AM, Mahmoud Al-Qudsi wrote:
>
>> Hello list,
>>
>> Another complaint about `llvm60` here - I was hoping that the situation
>> would be
>> ameliorated before the release of FreeBSD 12, but alas that is not the case.
>>
>> From what I understand, `mesa-dri` doesn't build out-of-the-box with
>> `llvm70`.
>> Cool. But that makes `llvm60` a build dependency for `mesa-dri` - the binary
>> package should not require installing 813 MiB's worth of compilers,
>> documentation, etc. just to run something built with that toolchain.
>>
>> Surely the runtime components of `llvm60` sufficient to use libraries built
>> with
>> that toolchain can be split off into their own package? Even better, perhaps
>> `mesa-dri` can be statically compiled? (I know it has C++ components, but I'm
>> not sure if they ever cross the API barrier -- I haven't looked into it
>> though,
>> so it's just wild speculation on my part.)
>>
>> (I do see that there exists a patch for getting `mesa-dri` to build with
>> `llvm70` hopefully making this conversation somewhat moot, but I still
>> strongly
>> object to the principle of adding such massive dependencies for common
>> packages.)
>>
>
>
> This has been discussed several times in the past. Mesa uses
> libraries and components of llvm that are not in base, hence the
> dependency on the ports version of llvm. This also untangles some of
> the issues with llvm library usage, since we only have to support one
> version of llvm usage in mesa, regardless of FreeBSD version.
>
> Since mesa uses llvm libraries (not just toolchain to build) this can
> not be made in to a build time only dependency.
Did anyone actually try to switch mesa-* ports to --disable-llvm-shared-libs?
In the past libLLVM.so caused crashes when another application/library/plugin
loaded a different version of it due to GLOBAL bindings.
$ readelf -a /usr/local/llvm*/lib/libLLVM.so | fgrep LLVMContextCreate
6561: 0077166037 FUNCGLOBAL DEFAULT 11 LLVMContextCreate
36811: 0077166037 FUNCGLOBAL DEFAULT 11 LLVMContextCreate
5310: 007556b037 FUNCGLOBAL DEFAULT 11 LLVMContextCreate
38133: 007556b037 FUNCGLOBAL DEFAULT 11 LLVMContextCreate
6964: 016be10037 FUNCGLOBAL DEFAULT 15
LLVMContextCreate@@LLVM_5.0
47409: 016be10037 FUNCGLOBAL DEFAULT 15 LLVMContextCreate
23143: 01a0ab0037 FUNCGLOBAL DEFAULT 15
LLVMContextCreate@@LLVM_6.0
46948: 01a0ab0037 FUNCGLOBAL DEFAULT 15 LLVMContextCreate
7565: 01b7281037 FUNCGLOBAL DEFAULT 15
LLVMContextCreate@@LLVM_7
52448: 01b7281037 FUNCGLOBAL DEFAULT 15 LLVMContextCreate
Let's imitate what may happen at runtime.
$ cat >a.c
#include
int main()
{
LLVMContextCreate();
return 0;
}
$ cc a.c $(llvm-config70 --libs --ldflags --cppflags)
$ ldd a.out | fgrep llvm
libLLVM-7.so => /usr/local/llvm70/lib/libLLVM-7.so (0x80040)
$ ./a.out
$ LD_PRELOAD=/usr/local/llvm39/lib/libLLVM.so ./a.out
Assertion failed: (count_if(RegisteredOptionCategories, [cat](const
OptionCategory *Category) { return cat->getName() == Category->getName(); }) ==
0 && "Duplicate option categories"), function registerCategory, file
/usr/ports/devel/llvm39/work/llvm-3.9.1.src/lib/Support/CommandLine.cpp, line
278.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: replacement for xmms?
On 17 Jan 2019, at 05:53, Robert Huff wrote: > Samy Mahmoudi writes: >> Why do you need a replacement for xmms ? > Because it's no longer in the ports tree? /usr/ports/audio/xmms2 /usr/ports/audio/gxmms2 Is there an issue with xmms2? -- I loved you when our love was blessed I love you now there's nothing left But sorrow and a sense of overtime ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Separate build/runtime llvm60 dependencies
On 1/17/19 12:17 AM, Mahmoud Al-Qudsi wrote: Hello list, Another complaint about `llvm60` here - I was hoping that the situation would be ameliorated before the release of FreeBSD 12, but alas that is not the case. From what I understand, `mesa-dri` doesn't build out-of-the-box with `llvm70`. Cool. But that makes `llvm60` a build dependency for `mesa-dri` - the binary package should not require installing 813 MiB's worth of compilers, documentation, etc. just to run something built with that toolchain. Surely the runtime components of `llvm60` sufficient to use libraries built with that toolchain can be split off into their own package? Even better, perhaps `mesa-dri` can be statically compiled? (I know it has C++ components, but I'm not sure if they ever cross the API barrier -- I haven't looked into it though, so it's just wild speculation on my part.) (I do see that there exists a patch for getting `mesa-dri` to build with `llvm70` hopefully making this conversation somewhat moot, but I still strongly object to the principle of adding such massive dependencies for common packages.) This has been discussed several times in the past. Mesa uses libraries and components of llvm that are not in base, hence the dependency on the ports version of llvm. This also untangles some of the issues with llvm library usage, since we only have to support one version of llvm usage in mesa, regardless of FreeBSD version. Since mesa uses llvm libraries (not just toolchain to build) this can not be made in to a build time only dependency. There is some more information on this issue here: https://wiki.freebsd.org/WhyDoIHaveToBuildLLVMWhenIAlreadyHaveClangInstalled There is work in progress to move to llvm70, however, this only means that you need llvm70 installed alongside mesa-dri, instead of llvm60. Regards! -- Niclas FreeBSD Graphics Team ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: replacement for xmms?
Samy Mahmoudi writes: > Why do you need a replacement for xmms ? Because it's no longer in the ports tree? Respectfully, Robert Huff ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: replacement for xmms?
xmms was so great ! I still use it and even managed to build a pulseaudio plugin last year, as I needed to be able to switch between outputs while playing (can OSS do that ?). Why do you need a replacement for xmms ? I have personally noticed some minor problems with xmms: • old-style GTK+ menu • accented characters don't display correctly • while xmms is running, I can't easily switch between virtual desktops (xfce4 + compiz) • audio format compatibility (still pretty large with plugins) I will have a look at the recently deprecated x11/gtk-theme-switch and the gtkrc file for the first two problems, although looking for a modern alternative is probably the best way to go. Le jeu. 17 janv. 2019 à 01:27, Robert Huff a écrit : > > I'm looking for something not too complicated, that runs in a > GUI. > Suggestions? > > > Respectfully, > > > Robert Huff > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: replacement for xmms?
"Jack L." wrote: > audacious, there's even a skin to make it look identical to xmms > (well, almost) Available in 'audacious-skins' $ pkg install audacious-skins Emanuel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
