Re: Fwd: Building gcc-4.9 on OpenBSD
On 20/09/14 02:45, Ian Grant wrote: > You get first prize for most informative intelligent answer so far! > Careful, you might get second prize too :-) > > The problem is that we need to find a way to tell people _what_ is in > that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and > goes about its business. That's probably why OpenBSD gcc 4.9 binaries > are 17MB against the 64MB compiled by gcc 4.9. But that is a really > fucking big dwarf they're stuffing in threre. What is the data, > really? We can't just say "it's dwarf" because that doesn't really > mean a whole lot, does it? It's debugging information for debuggers. What more are you asking for? Do you need to know about the structure of the debuginfo, or something? Andrew.
Re: Fwd: Building gcc-4.9 on OpenBSD
On Sat, Sep 20, 2014 at 08:33:01AM +0100, Andrew Haley wrote: > On 20/09/14 02:45, Ian Grant wrote: > > > You get first prize for most informative intelligent answer so far! > > Careful, you might get second prize too :-) > > > > The problem is that we need to find a way to tell people _what_ is in > > that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and > > goes about its business. That's probably why OpenBSD gcc 4.9 binaries > > are 17MB against the 64MB compiled by gcc 4.9. But that is a really > > fucking big dwarf they're stuffing in threre. What is the data, > > really? We can't just say "it's dwarf" because that doesn't really > > mean a whole lot, does it? > > It's debugging information for debuggers. What more are you asking > for? Do you need to know about the structure of the debuginfo, or > something? And if you need that, it is easily available, see http://www.dwarfstd.org/ https://fedorahosted.org/elfutils/wiki/DwarfExtensions . If you care only about what matters for execution of the generated binaries, it is only the allocated sections that matter (with A flag in readelf -WS output), and all the debug info is in non-allocated sections only. Jakub
Re: Implementing OpenACC's Fortran module
On 19.09.2014 11:03, Thomas Schwinge wrote:
Regarding linking the object file produced by Fortran openacc.f90 into
libgomp: (with the version that Jim already has internally checked in)
I find that libgomp then has undefined references to
_gfortran_internal_unpack and _gfortran_internal_pack.
Internal pack and unpack appears when you a (potentially) noncontiguous
array is passed as argument to an argument which requires a contiguous
argument. Internal pack checks at run time whether the argument is
contiguous - and if not it creates a temporary and copies the data to
the temporary ('copy in') - internal unpack ensures for all arrays but
intent(in) that the data is propagated back to the original one.
I am pretty sure that copy-in will break the OpenACC functions.
One possibility would be to mark the dummy arguments in openacc.f90 as
CONTIGUOUS. That way, no internal pack/unpack is called by openacc.f90.
(If one has a noncontiguous array, the caller of openacc.f90 will do the
copy in/out.)
Thus, you could try to add ", contiguous" to all procedures which take
an assumed-rank array "(..)" as argument.
Tobias
Re: Fwd: Building gcc-4.9 on OpenBSD
On 20 September 2014 00:52, Ian Grant wrote: > None of this is useful to me. I'm trying to make a case for why people > should have confidence in GNU software. You are NOT helping me in > that, I assure you, You seem to have already made up your mind it's GNU crap. Being insulting is a funny way to ask for help. > > We need to publish some simple steps that people can take to reassure > themselves that the 64MB binaries that GCC 4.9 produces on Linux > systems are normal and nothing to worry about, If you run strip on the binaries and they get smaller, that means the additional space is not taken up with executable code, but optional debug info (in the DWARF format). Unless your strip command has been compromised too, of course. If you're not familiar with the strip and size commands, or prepared to use their man pages, I have to wonder what sort of case you're able to make for having confidence in any software. > Why is that so hard? Where are the GCC experts on this list. Where are > the people that actually care about the reputation of the FSF? They've probably got better things to do than engage with someone who comes out with crap like "dangerous GNU crap".
Failue when trying to build native mingw32 4.9.1 gcc (c, c++, ada)
Hello, I'm trying to build a native mingw32 4.9.1 gcc (I want to build a 4.9.1 arm cross compiler, but I need a 4.9.1 host gcc for that, and the gcc that comes with mingw32 is 4.8.1) I configure with: ../../src/gcc-4.9.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T (This is extracted from the 4.8.1 mingw32 native compiler by "gcc -v") I'm getting the following error message - like ld does not recognize /mingw/lib: # @multilib_flags@ is still needed because this may use # /d/crossbuild/mingw32/gcc-4.9.1/./gcc/xgcc -B/d/crossbuild/mingw32/gcc-4.9.1/./gcc/ -L/d/crossbuild/mingw32/gcc-4.9.1/mingw32/winsup/mingw -L/d/crossbuild/mingw32/gcc-4.9.1/mingw32/winsup/w32api/lib -isystem /d/crossbuild/src/gcc-4.9.1/winsup/mingw/include -isystem /d/crossbuild/src/gcc-4.9.1/winsup/w32api/include -B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem /mingw/mingw32/sys-includeand -O2 -I../../../../src/gcc-4.9.1/libgcc/../winsup/w32api/include -g -O2 -D_USE_32BIT_TIME_T -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector directly. # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh ../../../../src/gcc-4.9.1/libgcc/../mkinstalldirs . cp -p -f libgcc.map libgcc.map.def && if [ ! -d ./shlib ]; then mkdir ./shlib; else true; fi && /d/crossbuild/mingw32/gcc-4.9.1/./gcc/xgcc -B/d/crossbuild/mingw32/gcc-4.9.1/./gcc/ -L/d/crossbuild/mingw32/gcc-4.9.1/mingw32/winsup/mingw -L/d/crossbuild/mingw32/gcc-4.9.1/mingw32/winsup/w32api/lib -isystem /d/crossbuild/src/gcc-4.9.1/winsup/mingw/include -isystem /d/crossbuild/src/gcc-4.9.1/winsup/w32api/include -B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem /mingw/mingw32/sys-include-O2 -I../../../../src/gcc-4.9.1/libgcc/../winsup/w32api/include -g -O2 -D_USE_32BIT_TIME_T -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.a.tmp -o ./shlib/libgcc_s_dw2-1.dll.tmp -g -O2 -D_USE_32BIT_TIME_T -B./ _chkstk_s.o _chkstk_ms_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o gthr-win32_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lmingwthrd -lmingw32 -lmingwex -lmoldname -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 && if [ -f ./shlib/libgcc_s_dw2-1.dll ]; then mv -f ./shlib/libgcc_s_dw2-1.dll ./shlib/libgcc_s_dw2-1.dll.backup; else true; fi && mv ./shlib/libgcc_s_dw2-1.dll.tmp ./shlib/libgcc_s_dw2-1.dll && mv ./shlib/libgcc_s.a.tmp ./shlib/libgcc_s.a c:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory c:\MinGW\mingw32\bin\ld.exe: cannot find -lmingwthrd c:\MinGW\mingw32\bin\ld.exe: cannot find -lmingw32 c:\MinGW\mingw32\bin\ld.exe: cannot find -lmingwex c:\MinGW\mingw32\bin\ld.exe: cannot find -lmoldname c:\MinGW\min
