Re: gcc-8-cross-mipsen_2_amd64.changes REJECTED
First of all, I don't see any valid reason why ftp-master would reject that upload. There are certainly more packages which are not binNMUable. Plus binNMUs don't make any sense because the library packages are arch all packages, which need a sourceful upload anyway. If we have to uglify the release string, then please just add a "c" instead of "cross". On 13.01.19 05:36, YunQiang Su wrote: > Ohhh. wrong patches attached. I submit a bug to gcc-8-cross > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919141 > > Can you consider this patch? > > YunQiang Su 于2019年1月10日周四 下午11:53写道： > >> >> Please review my attached patch. >> >> Or by debdiff >> http://deb.debian.org/debian/pool/main/g/gcc-8-cross/gcc-8-cross_24.dsc >> >> http://mips64el.bfsu.edu.cn/debian/gcc-8-cross-mipsen/gcc-8-cross_25~cross1.dsc >> >> >> YunQiang Su 于2019年1月10日周四 上午11:09写道： >>> >>> Bastian Blank 于2018年8月23日周四 上午1:37写道： On Wed, Aug 22, 2018 at 08:27:29AM +0200, Matthias Klose wrote: > On 22.08.2018 06:00, Bastian Blank wrote: >> The version of the source package (2) does not show up in the binary >> version. >> So neither rebuilds with a new changelog, nor bin-nmus will work. You >> already >> add a "cross1", so why not add it there? > that's how it is done for all cross packages. The code is just a branch > of the > orgiginal gcc cross packaging. So apparently it is fine, or was fine with > ftp-masters? I don't know. Given that packages with overriden versions are particularly rare, it could just be an oversight. >Is there more than that to reject the package? Please > reconsider. If you fix this problem with the next uploads of all affected packages, which seems to be more then this one. >>> >>> I guess we need these packages more now, as MIPS open is r6. >>> Let's figure a solution: >>> >>> How about: >>>add an `~crossN' in the source packages, and grep it from changelog >>> in debian/rules >>> Is it acceptable? >>> >>> I will figure out one and upload to some else where. >>> Bastian -- First study the enemy. Seek weakness. -- Romulan Commander, "Balance of Terror", stardate 1709.2
Re: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8
On 12.01.19 21:37, Chaim Zax wrote:
> Hi, autoconf developers, Debian gcc maintainers,
>
> In Debian there is a bug [1] reported on the autoconf package which
> relates to a change in gcc 8. After looking into the issue it's not
> completely clear to me what the best solution should be.
>
> The autoconf function AC_SEARCH_LIBS check the availability of a
> specific library by generating and compiling a small c++ program. From
> gcc version 8 on this seems to fail for some libraries (e.g. atomic),
> but not all (we haven't seen major fallout so far).
>
> To reproduce this issue the following configure.ac script can be used:
>
> $ cat configure.ac
> AC_INIT
> AC_PROG_CXX
> AC_LANG([C++])
> AC_SEARCH_LIBS([__atomic_load_8],[atomic])
>
> $ autoconf
>
>
> When configured (build) with g++ 7 the result is correct, as expected:
>
> $ CXX=g++-7 ./configure
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++-7 accepts -g... yes
> checking for library containing __atomic_load_8... -latomic
>
>
> But when configured (build) with g++ 8 the atomic library is not found:
>
> $ CXX=g++-8 ./configure
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++-8 accepts -g... yes
> checking for library containing __atomic_load_8... no
>
>
> The c++ file generated is:
>
> /* confdefs.h */
> #define PACKAGE_NAME ""
> #define PACKAGE_TARNAME ""
> #define PACKAGE_VERSION ""
> #define PACKAGE_STRING ""
> #define PACKAGE_BUGREPORT ""
> #define PACKAGE_URL ""
> /* end confdefs.h. */
>
> /* Override any GCC internal prototype to avoid an error.
>Use char because int might match the return type of a GCC
>builtin and then its argument prototype would still apply. */
> #ifdef __cplusplus
> extern "C"
> #endif
> char __atomic_load_8 ();
> int
> main ()
> {
> return __atomic_load_8 ();
> ;
> return 0;
> }
>
>
> When compiled with g++ 7 it only gives a warning, the function arguments
> of '__atomic_load_8' are missing:
>
> $ g++-7 -o conftest -g -O2 test.cpp -latomic
> test.cpp:16:6: warning: new declaration ‘char __atomic_load_8()’
> ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const
> volatile void*, int)’ [-Wbuiltin-declaration-mismatch]
> char __atomic_load_8 ();
> ^~~
>
>
> When compiled with g++ 8 it fails with an compilation error, the missing
> arguments are now resulting in an error:
>
> $ g++-8 -o conftest -g -O2 test.cpp -latomic
> test.cpp:16:6: error: new declaration ‘char __atomic_load_8()’
> ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const
> volatile void*, int)’ [-fpermissive]
> char __atomic_load_8 ();
> ^~~
> test.cpp: In function ‘int main()’:
> test.cpp:20:25: error: too few arguments to function ‘long unsigned int
> __atomic_load_8(const volatile void*, int)’
> return __atomic_load_8 ();
>
>
> This error is interpreted by autoconf, which concludes the library is
> not available. When the generated c++ file is changed to use a different
> function from different library (e.g. the 'exp' function from 'libm')
> the file [2] does compile with c++ 8.
>
> $ g++-8 -o conftest -g -O2 exp.cpp -latomic
> exp.cpp:16:6: warning: declaration of ‘char exp()’ conflicts with
> built-in declaration ‘double exp(double)’ [-Wbuiltin-declaration-mismatch]
> char exp();
> ^~~
>
>
> To know the impact of this bug on other Debian packages it's important
> to know when g++ will produce an error, and when only a warning. We
> suspect only the libraries provided by gcc itself seem to produce this
> error (although we haven't investigated that further), otherwise it
> would be likely lots of other Debian packages would produce this error
> as well. Perhaps someone knows exactly when g++ triggers this error, and
> possibly on which libraries? When updating autoconf it might be
> interesting to know if there is a compilation flag to change this error
> to a warning.
>
> To fix this issue it's most likely autoconf itself that needs to be
> updated as well. If this check only fails on libraries provided with g++
> the usage of the AC_SEARCH_LIBS function is probably not needed at all
> to check the availability on these libraries, Debian's package
> dependencies will automatically make sure these libraries will be
> available when autoconf is installed.
>
> Because autoconf can be used outside a Debian environment this solution
> might not work for everyone. Perhaps the AC_SEARCH_LIBS
"-fstack-clash-protection" option
Hi, I've read systemd's vulnerability article [1] and then I have a question, do we have any plan to enable "-fstack-clash-protection" by default? I cannot find any discussion about it. [1] https://www.zdnet.com/article/new-linux-systemd-security-holes-uncovered/ -- Hideki Yamane
Nowoczesna Strona lub Sklep internetowy, zobacz!
Dzień dobry, specjalizujemy się w realizacji projektów nowoczesnych *Sklepów* i *Stron internetowych*. Będzie nam bardzo miło, jeśli wyrazicie Państwo zainteresowanie naszą propozycją. Aby to zrobić wystarczy odpisać*/ tak /*na tego e-mail’a. Łączymy pozdrowienia, Pracownicy Działu Kreatywnego
