Re: [arch-general] [arch-dev-public] Changing compilation flags

2017-07-08 Thread Eli Schwartz via arch-general
On 07/08/2017 06:53 AM, LoneVVolf wrote:
> On 08-07-17 04:31, Evangelos Foutras via arch-general wrote:
>> There are multiple ways the compiler can be selected; two of them are: 1)
>> exporting CC/CXX in the PKGBUILD and 2) the project's configure script
>> picking one of the available compilers. makepkg can't realistically know
>> which compiler is going to be used and thus must have only one set of flags
>> that is supported by both GCC and Clang.
>>
> 
> An alternative solution would be to tailor things to the compiler used 
> by the majority (gcc) and to avoid clang as much as possible.
> That would ocourse require special settings for packages compiled with 
> clang.
> 
> NOTE : whether that is a good idea is another matter, but it IS an option.

AIUI that is already what we do, in the sense that gcc is the assumed
default everywhere, and our (C|CXX|LD)FLAGS are written with the
assumption that gcc is the default compiler.

Any packages that need to deviate from the default makepkg.conf flags
(because they *already* have special settings to use clang, those
settings are in the project build configuration files) can currently
modify those flags on a PKGBUILD-by-PKGBUILD basis, or alternatively we
can try to get clang to deal with basic gcc compatibility in a graceful
manner.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


[arch-general] [SOLVED] Re: Poor performance wifi BCM4331 - MacBookPro

2017-07-08 Thread Maykel Franco via arch-general
Bradley thanks for all.

I install the broadcom-wl-dkms and later, pacman -Syu and add dkms
module in the kernel.

Now the wifi is more efficient, speed and stability.

Thanks for all.

T

2017-07-07 23:29 GMT+02:00 Bradley Klee via arch-general
:
> Hi Maykel,
>
> Don't confuse me for an expert, but I have been dealing with Broadcom issue 
> on a recycled dell laptop.
>
> According to the wiki, Broadcom devices have been historically difficult for 
> Linux developers to work with. Replacement hardware could be a better option, 
> but in the meantime wireless seems to work in my case using the "dkms" 
> package.
>
> If Installing this you should read the following:
>
> https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support
>
> Adding a dkms package will change your update procedure, sometimes making 
> additional work for pacman.
>
> In case you didn't find the MacBook-specific wiki page, which also mentions 
> Broadcom issues, try looking around here:
>
> https://wiki.archlinux.org/index.php/MacBookPro11,x
> https://wiki.archlinux.org/index.php/MacBookPro7,1
>
> Also, this topic is on numerous BBS threads, so you may want to try a google 
> search, such as: "broadcom macbook 4331 site:bbs.archlinux.org" .
>
> Hope this helps,
>
> Brad
>
>
>
>
> On Jul 7, 2017, at 2:34 PM, Maykel Franco via arch-general 
>  wrote:
>
>> Hi, I have install archlinux in my MacBookPro with this wifi hardware:
>>
>> Broadcom Limited BCM4331 802.11a/b/g/n
>>
>> In the wiki arch:
>>
>> https://wiki.archlinux.org/index.php/broadcom_wireless
>>
>> BCM4331 noticed to have problems with b43-firmware-classic. Use
>> b43-firmware for this card instead.
>>
>> I probed with b43-firmware-classic community and b43-firmware yaourt
>> and both poor performance... 900k bandwith and microcuts.
>>
>> I will try broadcom-wl because I see in this link:
>>
>> https://www.reddit.com/r/archlinux/comments/5qlyfm/cant_get_wifi_with_broadcom_bcm4331_chip/
>>
>> Too I see broadcom-wl-dkms but I have the default kernel no dkms.
>>
>> Somebody with the same problem??


Re: [arch-general] [arch-dev-public] Changing compilation flags

2017-07-08 Thread LoneVVolf

On 08-07-17 04:31, Evangelos Foutras via arch-general wrote:

There are multiple ways the compiler can be selected; two of them are: 1)
exporting CC/CXX in the PKGBUILD and 2) the project's configure script
picking one of the available compilers. makepkg can't realistically know
which compiler is going to be used and thus must have only one set of flags
that is supported by both GCC and Clang.



An alternative solution would be to tailor things to the compiler used 
by the majority (gcc) and to avoid clang as much as possible.
That would ocourse require special settings for packages compiled with 
clang.


NOTE : whether that is a good idea is another matter, but it IS an option.