Finding shared library dependencies when linking executable - gcc

I am attempting to cross-compile gstreamer for ARM hosts on a Ubuntu 12.04 (32-bit) build system. None of what I'm about to describe happens with the i686-linux-gnu GCC. I am compiling on Ubuntu 12.04 using this gcc:
> arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6
--enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabihf/include/c++/4.6.3 --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib
--disable-sjlj-exceptions --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
--with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
--with-headers=/usr/arm-linux-gnueabihf/include
--with-libs=/usr/arm-linux-gnueabihf/lib
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
And this ld:
arm-linux-gnueabihf-ld -v
GNU ld (GNU Binutils for Ubuntu) 2.22
GCC was installed from the default Ubuntu 12.04 PPAs. When the build system gets to linking the gst-discoverer-1.0 executable, I get the following error:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/bin/ld: warning: liborc-0.4.so.0, needed by ../gst-libs/gst/video/.libs/libgstvideo-1.0.so, not found (try using -rpath or -rpath-link)
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_program_compile'
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_program_set_backup_function'
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_program_new_from_static_bytecode'
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_program_free'
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_once_mutex_lock'
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_program_take_code'
../gst-libs/gst/video/.libs/libgstvideo-1.0.so: undefined reference to `orc_once_mutex_unlock'
collect2: ld returned 1 exit status
gst-discoverer-1.0 depends on libgstvideo-1.0.so. libgstvideo-1.0.so (which was built successfully earlier in the process) has a dependency on liborc-0.4.so. Inspecting the libgstvideo-1.0.so with arm-linux-gnueabihf-readelf -a yields the following snippet:
Dynamic section at offset 0x29ed8 contains 33 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libgstbase-1.0.so.0]
0x00000001 (NEEDED) Shared library: [libgstreamer-1.0.so.0]
0x00000001 (NEEDED) Shared library: [libgobject-2.0.so.0]
0x00000001 (NEEDED) Shared library: [libglib-2.0.so.0]
0x00000001 (NEEDED) Shared library: [liborc-0.4.so.0]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000e (SONAME) Library soname: [libgstvideo-1.0.so.0]
0x0000000f (RPATH) Library rpath: [/home/test/gst/gstreamer/gstreamer/libs/gst/base/.libs:/
home/test/gst/gstreamer/gstreamer/gst/.libs:/home/test/gst/gstreamer/orc/orc/.libs]
The path to liborc-0.4.so in the RPATH entry is correct. The link line for gst-discoverer-1.0 does not contain references to liborc because it is not directly dependent on it (only indirectly dependent via libgstvideo-1.0.so). I have tried adding "-rpath-link=/home/test/gst/gstreamer/orc/orc/.libs" to my LDFLAGS, but it didn't work. Any ideas about why the cross-compile linker is not able to find a dependency of this shared library?

It seems I was on the right track, but I was passing -rpath-link to ld (using LDFLAGS on my configure line). Since it is gcc that is actually doing the linking, I need to use CFLAGS and the -Wl argument like this:
./configure CFLAGS="-Wl,-rpath=/home/test/gst/gstreamer/orc/orc/libs"
According to some, there might be a bug in the cross-linker.

Related

Many "multiple definition of" errors shows up when compiling TPC-DS tools

I'm trying to compile TPC-DS tools (i..e Tools used to benchmark databases) but I'm seeing the following errors:
$ make
gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DYYDEBUG -DLINUX -g -Wall -o dsdgen s_brand.o s_customer_address.o s_call_center.o s_catalog.o s_catalog_order.o s_catalog_order_lineitem.o s_catalog_page.o s_catalog_promotional_item.o s_catalog_returns.o s_category.o s_class.o s_company.o s_customer.o s_division.o s_inventory.o s_item.o s_manager.o s_manufacturer.o s_market.o s_pline.o s_product.o s_promotion.o s_purchase.o s_reason.o s_store.o s_store_promotional_item.o s_store_returns.o s_subcategory.o s_subclass.o s_warehouse.o s_web_order.o s_web_order_lineitem.o s_web_page.o s_web_promotinal_item.o s_web_returns.o s_web_site.o s_zip_to_gmt.o w_call_center.o w_catalog_page.o w_catalog_returns.o w_catalog_sales.o w_customer_address.o w_customer.o w_customer_demographics.o w_datetbl.o w_household_demographics.o w_income_band.o w_inventory.o w_item.o w_promotion.o w_reason.o w_ship_mode.o w_store.o w_store_returns.o w_store_sales.o w_timetbl.o w_warehouse.o w_web_page.o w_web_returns.o w_web_sales.o w_web_site.o dbgen_version.o address.o build_support.o date.o decimal.o dist.o driver.o error_msg.o genrand.o join.o list.o load.o misc.o nulls.o parallel.o permute.o pricing.o print.o r_params.o StringBuffer.o tdef_functions.o tdefs.o text.o scd.o scaling.o release.o sparse.o validate.o -lm
/usr/bin/ld: s_purchase.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_purchase.c:55: multiple definition of `nItemIndex'; s_catalog_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_catalog_order.c:56: first defined here
/usr/bin/ld: s_web_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_order.c:56: multiple definition of `nItemIndex'; s_catalog_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_catalog_order.c:56: first defined here
/usr/bin/ld: s_web_order_lineitem.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_order_lineitem.c:54: multiple definition of `g_s_web_order_lineitem'; s_web_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_order.c:54: first defined here
/usr/bin/ld: w_catalog_page.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/w_catalog_page.c:52: multiple definition of `g_w_catalog_page'; s_catalog_page.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_catalog_page.c:51: first defined here
/usr/bin/ld: w_warehouse.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/w_warehouse.c:53: multiple definition of `g_w_warehouse'; s_warehouse.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_warehouse.c:51: first defined here
/usr/bin/ld: w_web_site.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/w_web_site.c:59: multiple definition of `g_w_web_site'; s_web_site.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_site.c:51: first defined here
collect2: error: ld returned 1 exit status
make: *** [makefile:233: dsdgen] Error 1
After searching around, I found that older GCC versions tolerated this mistake, and using the -fcommong GCC option should tolerate the duplicate declarations, but it didn't:
$ make
gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DYYDEBUG -DLINUX -g -Wall -fcommon -o dsdgen s_brand.o s_customer_address.o s_call_center.o s_catalog.o s_catalog_order.o s_catalog_order_lineitem.o s_catalog_page.o s_catalog_promotional_item.o s_catalog_returns.o s_category.o s_class.o s_company.o s_customer.o s_division.o s_inventory.o s_item.o s_manager.o s_manufacturer.o s_market.o s_pline.o s_product.o s_promotion.o s_purchase.o s_reason.o s_store.o s_store_promotional_item.o s_store_returns.o s_subcategory.o s_subclass.o s_warehouse.o s_web_order.o s_web_order_lineitem.o s_web_page.o s_web_promotinal_item.o s_web_returns.o s_web_site.o s_zip_to_gmt.o w_call_center.o w_catalog_page.o w_catalog_returns.o w_catalog_sales.o w_customer_address.o w_customer.o w_customer_demographics.o w_datetbl.o w_household_demographics.o w_income_band.o w_inventory.o w_item.o w_promotion.o w_reason.o w_ship_mode.o w_store.o w_store_returns.o w_store_sales.o w_timetbl.o w_warehouse.o w_web_page.o w_web_returns.o w_web_sales.o w_web_site.o dbgen_version.o address.o build_support.o date.o decimal.o dist.o driver.o error_msg.o genrand.o join.o list.o load.o misc.o nulls.o parallel.o permute.o pricing.o print.o r_params.o StringBuffer.o tdef_functions.o tdefs.o text.o scd.o scaling.o release.o sparse.o validate.o -lm
/usr/bin/ld: s_purchase.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_purchase.c:55: multiple definition of `nItemIndex'; s_catalog_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_catalog_order.c:56: first defined here
/usr/bin/ld: s_web_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_order.c:56: multiple definition of `nItemIndex'; s_catalog_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_catalog_order.c:56: first defined here
/usr/bin/ld: s_web_order_lineitem.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_order_lineitem.c:54: multiple definition of `g_s_web_order_lineitem'; s_web_order.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_order.c:54: first defined here
/usr/bin/ld: w_catalog_page.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/w_catalog_page.c:52: multiple definition of `g_w_catalog_page'; s_catalog_page.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_catalog_page.c:51: first defined here
/usr/bin/ld: w_warehouse.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/w_warehouse.c:53: multiple definition of `g_w_warehouse'; s_warehouse.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_warehouse.c:51: first defined here
/usr/bin/ld: w_web_site.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/w_web_site.c:59: multiple definition of `g_w_web_site'; s_web_site.o:/home/mgelbana/workspace/tools/TPC/TPC-DS/DSGen-software-code-3.2.0rc1/tools/s_web_site.c:51: first defined here
collect2: error: ld returned 1 exit status
make: *** [makefile:233: dsdgen] Error 1
I can't modify this tool, and its docs don't say which GCC version I should use to compile it.
My GCC version is:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
So is there a way to configure my GCC to tolerate this declaration issue? Or at least configure it to behave as an older version of itself (Compatibility mode?) so I can try different versions until one works?
The solution is to clean things up and use GCC v9:
make clean
make CC=gcc-9
Or you can set the OS relevant CC variable to the equivalent GCC v9 command. In my case, as I'm using Linux, the variable ended up as follows:
LINUX_CC = gcc-9

warnings while trying to compile old linux kernel with gcc 12.1.0

I am currently hunting a bug using git bisect in linux staging-testing tree.
Some commits are giving following errors after I try to build them:
subcmd-util.h:58:31: error: pointer may be used after ‘realloc’ [-Werror=use-after-free]
58 | ret = realloc(ptr, 1);
check.c:2867:58: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=]
2867 | snprintf(pvname, sizeof(pvname), "pv_ops[%d]", idx);
I tried adding -Wno-error=use-after-free to KBUILD_FLAGS in main Makefile, tried adding
KBUILD_CFLAGS += $(call cc-disable-warning, use-after-free)
I even tried removing -Werror from CFLAGS in Makefile in folder where problematic files are located, but nothing worked.
More information:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.artixlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Linux staging tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git.
One of the commits that gives following warnings: 2ab9c9675fe892e7fe9fa8c0a6125e2b40d2889d.
To compile older version of kernel I needed older compiler ("Linux kernel sources are in general not forward-compatible with new compilers"). In my case the kernel version was 5.16.0 and I could compile it with gcc 11. If you have gcc 11 specific warnings then try gcc 10 and so on.
Except CC flags, I also needed set to HOSTCC flags to use gcc-11 compiler:
make HOSTCC=gcc-11 CC=gcc-11

CodeSourcery ARM cross-compilation

Compiling a simple test.c:
#include <stdio.h>
void main() {
printf("Hello World!\n");
while(1);
}
using CodeSourcery's arm-none-eabi-gcc I got the following errors:
arm-none-eabi-gcc -static test.c -o mytest
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol _start; defaulting to 00008018
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x20): undefined reference to `_write'
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x18): undefined reference to `_close'
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text+0x1c): undefined reference to `_fstat'
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text+0x18): undefined reference to `_isatty'
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text+0x20): undefined reference to `_lseek'
/opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text+0x20): undefined reference to `_read'
collect2: error: ld returned 1 exit status
But if i used my Ubuntu (12.04 LTS 32-bit) 's arm gcc:
arm-linux-gnueabi-gcc -static -o mytest test.c
arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
I have no error generating the output file.
can someone explain?
My best nearest reference (but still I have no success):
Linker error on a C project using eclipse
arm-none-eabi-gcc is a compiler for bare metal arm. I.e. for running on an arm processor where you have no operating system, or where you make your own operating system. That compiler contains the newlib C library, which will provide you with most of a standard C library, but you will have to provide the low level implementations (e.g. somewhere for printf() to actually print, memory management, a file system if you need it). In short, you're much on your own having to bootstrap the processor, C runtime and load the produced code (See e.g. this question))
arm-linux-gnueabi-gcc is a compiler for targeting linux running on arm, a toolchain that'll produce executables running on linux, using the familiar glibc C library and header files.

Problems compiling gfortran in Cygwin with large memory requirements

My computer (intel core i7 CPU, 20 GB RAM, 2TB HDD) is running Windows 8 and I usually boot up the Linux VM to do my programming, but I am currently trying to run a Fortran program natively in Windows 8 using Cygwin. I am writing a program which has large memory requirements and I am creating a double precision array of size 13943 x Nfiles where I let Nfiles vary and I am trying to make it as large as possible while still remaining under 20 GB of RAM.
I notice that when I get to around Nfiles = 17000 it uses about 1.77 GB of RAM. However, when I raise Nfiles to 20000, I get a compilation error of
gfortran -ffixed-line-length-132 -fimplicit-none -O2 -o smear_sfs.exe xdriver.F90 modules.o
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/crtbegin.o:cygming-crtbegin.c:(.text+0x2b): relocation truncated to fit: R_X86_64_PC32 against symbol `__imp_GetModuleHandleA' defined in .idata$5 section in /usr/lib/w32api/libkernel32.a(dysgbs00548.o)
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/crtbegin.o:cygming-crtbegin.c:(.text+0x47): relocation truncated to fit: R_X86_64_PC32 against symbol `__imp_GetProcAddress' defined in .idata$5 section in /usr/lib/w32api/libkernel32.a(dysgbs00598.o)
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld: /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/crtbegin.o: bad reloc address 0x0 in section `.pdata'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld: final link failed: Invalid operation
collect2: error: ld returned 1 exit status
Makefile:30: recipe for target `smear_sfs' failed
make: *** [smear_sfs] Error 1
But after searching online I cannot figure out what the problem is. gfortran -v reveals the following information
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.1-3/src/gcc-4.8.1/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.1-3/src/gcc-4.8.1 --prefix=/usr --exec- prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib
Thread model: posix
gcc version 4.8.1 (GCC)
so it seems like I am correctly using a 64-bit compiler on a 64-bit OS.
Any ideas?

-static option for gcc?

I'm wondering what the -static option on gcc does. I need this option when compiling a certain application, however when I do I get the following error:
gcc -static -O3 -o prog prog.c
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
What needs installation?
GCC version:
[user#localhost dir]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
The -static option links a program statically, in other words it does not require a dependency on dynamic libraries at runtime in order to run.
To achieve static linking requires that the archive (.a) versions of your libraries exist on the system. so /usr/lib/libc.a, /usr/lib/crt1.o, etc.
On modern linux systems (as you are using red hat): when a binary links together it 1) either puts the code into the executable via .o and .a files, or 2) puts in references to dynamic libraries (.so) files that is resolved by /lib/ld-linux.so (or /lib64/ld-linux=x86-64.so) which is always at a well known place.
For your particular system, if a program is specifically looking to create a static version of itself then you need to install the static versions of your devel tools. You need, at the minimum, glibc-static package. You may also need libstdc++-static package as well.
The -static flag forces the linker to accept only static libraries and not any shared libraries.
If you want to use -static, you have to ensure that you have a static version of the C library installed, which might be tricky to find (most systems do not have a static C library any more). Or you have to cancel the effect of -static. However, in the example, that would defeat the purpose of -static since the only library linked is (implicitly) the C library.
On systems that support dynamic linking, this overrides -pie and prevents linking with the shared libraries. On other systems, this option has no effect.
Ref: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Resources