Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Rainer Hurling]

On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote:

On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote:

Am 12/28/11 19:10, schrieb Ed Schouten:

* Rainer Hurlingrhur...@gwdg.de, 20111228 17:31:

error: macro _Static_assert passed 3 arguments, but takes just 2
In file included from 
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0:


Hmmm... This seems to apply to my changes. I will look into this
tomorrow. Thanks for the report!




Be aware that the error produced by the linker I mentioned in the
initial post occurs on FreeBSD 10 as well as FreeBSD 9.0.

I already filed a PR about the problem of a non compiling lang/gcc46
today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test
puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem.

I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0.


Obviously, linker error during the compilation of third-party software
has nothing to do with compiler error occuring when building gcc.

Do people ever read the texts of the messages ?


Kostik, probably you are right. I had read the messages, but there are 
some strange errors with gcc46 on head for two days now, which leaded me 
in the wrong direction. So sorry for erroneously 'hijacking' this thread 
with another problem most certain only existing in head.



I found another trail, which hopefully is more usefull for solving the 
problem Oliver described.


Whe I try to build lang/lua I get this error:

[..snip..]
cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3  -Wall 
-DLUA_USE_LINUX   -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o 
ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o 
lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o 
lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o 
lstrlib.o loadlib.o linit.o
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o 
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o 
ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o 
lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o

ranlib liblua.a
cc -o lua  lua.o liblua.a -lm -Wl,-E -lreadline
cc -o luac  luac.o print.o liblua.a -lm -Wl,-E -lreadline
/usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' 
can not be used when making a shared object; recompile with -fPIC

lapi.o: could not read symbols: Bad value
*** Error code 1


It also gives a linker error, almost the same relocation is named. This 
does only happen with option '-msse3' enabled in /etc/make.conf:


CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3

Using CLFAGS without -msse3 (default) works well:

CFLAGS= -O2 -fno-strict-aliasing -pipe


The systems processor, were this happens, is a

CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x100fa0  Family = 10  Model = a 
Stepping = 0

Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
  Features2=0x802009SSE3,MON,CX16,POPCNT
  AMD 
Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
  AMD 
Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT

  TSC: P-state invariant, performance statistics

FreeBSD 10-CURRENT (amd64) r228920

In hope of a more belonging posting,
Rainer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Kostik Belousov]

On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:
 Hello out here.
 
 I run into a problem since one of the last portupdates and I do not know
 whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
 AMD64.
 
 Background:
 We use a scientific graphical toolset for planetary research called
 ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
 couple of weeks ago.
 On all of my boxes, I do frequently a portupgrade, so I saw binutils got
 bumped up and gcc 4.6 is also getting really frequently changed these days.
 After a some portupdates within the last weeks, I just decided to
 compile ISIS3 again to keep it fresh and on track, but it won't
 compile anymore.
 
 On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
 CLANG built) I receive in some subfolders containing sources the
 follwoing error:
 
 [...]
 Adding API object [UniqueIOCachingAlgorithm]
 Adding API object [UniversalGroundMap]
 Adding API object [UserInterface]
 Adding API object [VariableLineScanCameraDetectorMap]
 Adding API object [VecFilter]
 Adding API object [WorldMapper]
 Adding API object [iException]
 Adding API object [iString]
 Adding API object [iTime]
   Working on Package [mex] (11:30:15)
 Adding API object [HrscCamera]
 /usr/local/bin/ld:
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
 relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
 can not be used when making a shared object; recompile with -fPIC
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
 could not read symbols: Bad value
 collect2: ld returned 1 exit status
 gmake[5]: *** [plugin] Error 1
 cp: libHrscCamera.so: No such file or directory
 gmake[4]: *** [install] Error 1
The error is completely clear as it is: the build tries to link static
library libstdc++.so into shared object. This is not supported.


pgpqYjyBtTIwA.pgp
Description: PGP signature

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[O. Hartmann]

Am 12/28/11 14:58, schrieb Kostik Belousov:
 On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:
 Hello out here.

 I run into a problem since one of the last portupdates and I do not know
 whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
 AMD64.

 Background:
 We use a scientific graphical toolset for planetary research called
 ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
 couple of weeks ago.
 On all of my boxes, I do frequently a portupgrade, so I saw binutils got
 bumped up and gcc 4.6 is also getting really frequently changed these days.
 After a some portupdates within the last weeks, I just decided to
 compile ISIS3 again to keep it fresh and on track, but it won't
 compile anymore.

 On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
 CLANG built) I receive in some subfolders containing sources the
 follwoing error:

 [...]
 Adding API object [UniqueIOCachingAlgorithm]
 Adding API object [UniversalGroundMap]
 Adding API object [UserInterface]
 Adding API object [VariableLineScanCameraDetectorMap]
 Adding API object [VecFilter]
 Adding API object [WorldMapper]
 Adding API object [iException]
 Adding API object [iString]
 Adding API object [iTime]
   Working on Package [mex] (11:30:15)
 Adding API object [HrscCamera]
 /usr/local/bin/ld:
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
 relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
 can not be used when making a shared object; recompile with -fPIC
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
 could not read symbols: Bad value
 collect2: ld returned 1 exit status
 gmake[5]: *** [plugin] Error 1
 cp: libHrscCamera.so: No such file or directory
 gmake[4]: *** [install] Error 1
 The error is completely clear as it is: the build tries to link static
 library libstdc++.so into shared object. This is not supported.

Thanks, Kostik, for the fast response.
The error isn't so clear to me, sorry. I thought libstdc++.a is the
static library and it is taken to be referenced/compiled into a shared
object created by the application I try to compile.

I'm much more confused now, since I thought the last time I compiled
that piece of software, I never got any error like that. Well, clang
fails with some obscure errors on the code itself and I'm unwilling to
correct them, I'll try the legacy gcc 4.2.1 and will report what's
happening.

Thank you very much,

Oliver



signature.asc
Description: OpenPGP digital signature

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Kostik Belousov]

On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote:
 Am 12/28/11 14:58, schrieb Kostik Belousov:
  On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:
  Hello out here.
 
  I run into a problem since one of the last portupdates and I do not know
  whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
  AMD64.
 
  Background:
  We use a scientific graphical toolset for planetary research called
  ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
  8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
  couple of weeks ago.
  On all of my boxes, I do frequently a portupgrade, so I saw binutils got
  bumped up and gcc 4.6 is also getting really frequently changed these days.
  After a some portupdates within the last weeks, I just decided to
  compile ISIS3 again to keep it fresh and on track, but it won't
  compile anymore.
 
  On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
  CLANG built) I receive in some subfolders containing sources the
  follwoing error:
 
  [...]
  Adding API object [UniqueIOCachingAlgorithm]
  Adding API object [UniversalGroundMap]
  Adding API object [UserInterface]
  Adding API object [VariableLineScanCameraDetectorMap]
  Adding API object [VecFilter]
  Adding API object [WorldMapper]
  Adding API object [iException]
  Adding API object [iString]
  Adding API object [iTime]
Working on Package [mex] (11:30:15)
  Adding API object [HrscCamera]
  /usr/local/bin/ld:
  /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
  relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
  can not be used when making a shared object; recompile with -fPIC
  /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
  could not read symbols: Bad value
  collect2: ld returned 1 exit status
  gmake[5]: *** [plugin] Error 1
  cp: libHrscCamera.so: No such file or directory
  gmake[4]: *** [install] Error 1
  The error is completely clear as it is: the build tries to link static
  library libstdc++.so into shared object. This is not supported.
 
 Thanks, Kostik, for the fast response.
 The error isn't so clear to me, sorry. I thought libstdc++.a is the
 static library and it is taken to be referenced/compiled into a shared
Linked in.

 object created by the application I try to compile.
Right, and this is not supported. Code linked into shared object must
be compiled PIC. An .a library usually does not contain objects compiled
by PIC, ld just dutifully reported back.

 
 I'm much more confused now, since I thought the last time I compiled
 that piece of software, I never got any error like that. Well, clang
 fails with some obscure errors on the code itself and I'm unwilling to
 correct them, I'll try the legacy gcc 4.2.1 and will report what's
 happening.

It might have worked by accident (because libstdc++.a objects referenced 
during the link did not carried unsupported relocations), or, much more
likely, the build system has changed and started doing stupid things.
It must not link static libraries into shared objects.

You should examine why it does this, and fix it. Changing compilers is
just wasting a time.


pgpkHA6aHIGk1.pgp
Description: PGP signature

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Dimitry Andric]

On 2011-12-28 11:48, O. Hartmann wrote:
...

/usr/local/bin/ld:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status


What happens if you compile and link the following simple program with
g++46:

#include iostream

int main(void)
{
std::cout  Hello World!  std::endl;
return 0;
}

Does it fail with the same type of link error, e.g. linking to the
libstdc++.a instead libstdc++.so?  It would be nice if you can add -v to
the command line, and paste the output here.

I suspect your g++46 port is busted, for some reason.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[O. Hartmann]

Am 12/28/11 16:57, schrieb Dimitry Andric:
 On 2011-12-28 11:48, O. Hartmann wrote:
 ...
 /usr/local/bin/ld:
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):

 relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
 can not be used when making a shared object; recompile with -fPIC
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:

 could not read symbols: Bad value
 collect2: ld returned 1 exit status
 
 What happens if you compile and link the following simple program with
 g++46:
 
 #include iostream
 
 int main(void)
 {
 std::cout  Hello World!  std::endl;
 return 0;
 }
 
 Does it fail with the same type of link error, e.g. linking to the
 libstdc++.a instead libstdc++.so?  It would be nice if you can add -v to
 the command line, and paste the output here.
 
 I suspect your g++46 port is busted, for some reason.

It works fine:

ohartmann@telesto: [~] g++46 -v -o muff muff.cpp
Using built-in specs.
COLLECT_GCC=g++46
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/lto-wrapper
Target: x86_64-portbld-freebsd9.0
Configured with: ./../gcc-4.6-20111209/configure --disable-nls
--enable-languages=c,c++,objc,fortran --libdir=/usr/local/lib/gcc46
--libexecdir=/usr/local/libexec/gcc46 --program-suffix=46
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--enable-languages=c,c++,objc,fortran,java --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc46
--build=x86_64-portbld-freebsd9.0
Thread model: posix
gcc version 4.6.3 20111209 (prerelease) (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-v' '-o' 'muff' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/cc1plus
-quiet -v muff.cpp -quiet -dumpbase muff.cpp -mtune=generic
-march=x86-64 -auxbase muff -version -o /var/tmp//ccu1eDPY.s
GNU C++ (FreeBSD Ports Collection) version 4.6.3 20111209 (prerelease)
(x86_64-portbld-freebsd9.0)
compiled by GNU C version 4.6.3 20111209 (prerelease), GMP
version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/lib/gcc46/include/c++/
 /usr/local/lib/gcc46/include/c++//x86_64-portbld-freebsd9.0
 /usr/local/lib/gcc46/include/c++//backward
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/include
 /usr/local/include
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/include-fixed
 /usr/include
End of search list.
GNU C++ (FreeBSD Ports Collection) version 4.6.3 20111209 (prerelease)
(x86_64-portbld-freebsd9.0)
compiled by GNU C version 4.6.3 20111209 (prerelease), GMP
version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1f5bea4d4b089362b811317a91015e20
COLLECT_GCC_OPTIONS='-v' '-o' 'muff' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/bin/as -v -o /var/tmp//ccblbg7V.o /var/tmp//ccu1eDPY.s
GNU assembler version 2.22 (x86_64-portbld-freebsd9.0) using BFD version
(GNU Binutils) 2.22
COMPILER_PATH=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/bin/
LIBRARY_PATH=/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/lib/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'muff' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/collect2
--eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o muff
/usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/crtbegin.o
-L/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3
-L/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/lib
-L/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../..
/var/tmp//ccblbg7V.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/crtend.o
/usr/lib/crtn.o
GNU ld (GNU Binutils) 2.22
  Supported emulations:
   elf_x86_64_fbsd
   elf_i386_fbsd
   elf_x86_64

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Rainer Hurling]

On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote:

On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote:

Am 12/28/11 14:58, schrieb Kostik Belousov:

On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:

Hello out here.

I run into a problem since one of the last portupdates and I do not know
whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
AMD64.

Background:
We use a scientific graphical toolset for planetary research called
ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
couple of weeks ago.
On all of my boxes, I do frequently a portupgrade, so I saw binutils got
bumped up and gcc 4.6 is also getting really frequently changed these days.
After a some portupdates within the last weeks, I just decided to
compile ISIS3 again to keep it fresh and on track, but it won't
compile anymore.

On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
CLANG built) I receive in some subfolders containing sources the
follwoing error:

[...]
 Adding API object [UniqueIOCachingAlgorithm]
 Adding API object [UniversalGroundMap]
 Adding API object [UserInterface]
 Adding API object [VariableLineScanCameraDetectorMap]
 Adding API object [VecFilter]
 Adding API object [WorldMapper]
 Adding API object [iException]
 Adding API object [iString]
 Adding API object [iTime]
   Working on Package [mex] (11:30:15)
 Adding API object [HrscCamera]
/usr/local/bin/ld:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake[5]: *** [plugin] Error 1
cp: libHrscCamera.so: No such file or directory
gmake[4]: *** [install] Error 1

The error is completely clear as it is: the build tries to link static
library libstdc++.so into shared object. This is not supported.


Thanks, Kostik, for the fast response.
The error isn't so clear to me, sorry. I thought libstdc++.a is the
static library and it is taken to be referenced/compiled into a shared

Linked in.


object created by the application I try to compile.

Right, and this is not supported. Code linked into shared object must
be compiled PIC. An .a library usually does not contain objects compiled
by PIC, ld just dutifully reported back.



I'm much more confused now, since I thought the last time I compiled
that piece of software, I never got any error like that. Well, clang
fails with some obscure errors on the code itself and I'm unwilling to
correct them, I'll try the legacy gcc 4.2.1 and will report what's
happening.


It might have worked by accident (because libstdc++.a objects referenced
during the link did not carried unsupported relocations), or, much more
likely, the build system has changed and started doing stupid things.
It must not link static libraries into shared objects.

You should examine why it does this, and fix it. Changing compilers is
just wasting a time.



Hmm, I get a similar error when trying to build lang/gcc46 on recent 
10-CURRENT:



[..snip..]
Making all in include
gmake[4]: Entering directory 
`/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include'

mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch
/usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc 
-B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++ 
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src 
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs 
-B/usr/local/x86_64-portbld-freebsd10.0/bin/ 
-B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem 
/usr/local/x86_64-portbld-freebsd10.0/include -isystem 
/usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header 
-nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing 
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0 
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include 
-I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2 
-g -std=gnu++0x 
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h 
\

-o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from 
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0,
 from 
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100:
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/ratio:133:31: 
error: macro _Static_assert passed 3 

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[O. Hartmann]

Am 12/28/11 17:31, schrieb Rainer Hurling:
 On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote:
 On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote:
 Am 12/28/11 14:58, schrieb Kostik Belousov:
 On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:
 Hello out here.

 I run into a problem since one of the last portupdates and I do not
 know
 whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
 AMD64.

 Background:
 We use a scientific graphical toolset for planetary research called
 ISIS3, which is provided by the USGS. We patched ISIS3 to run on
 FreeBSD
 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
 couple of weeks ago.
 On all of my boxes, I do frequently a portupgrade, so I saw
 binutils got
 bumped up and gcc 4.6 is also getting really frequently changed
 these days.
 After a some portupdates within the last weeks, I just decided to
 compile ISIS3 again to keep it fresh and on track, but it won't
 compile anymore.

 On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
 CLANG built) I receive in some subfolders containing sources the
 follwoing error:

 [...]
  Adding API object [UniqueIOCachingAlgorithm]
  Adding API object [UniversalGroundMap]
  Adding API object [UserInterface]
  Adding API object [VariableLineScanCameraDetectorMap]
  Adding API object [VecFilter]
  Adding API object [WorldMapper]
  Adding API object [iException]
  Adding API object [iString]
  Adding API object [iTime]
Working on Package [mex] (11:30:15)
  Adding API object [HrscCamera]
 /usr/local/bin/ld:
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):

 relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
 can not be used when making a shared object; recompile with -fPIC
 /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:

 could not read symbols: Bad value
 collect2: ld returned 1 exit status
 gmake[5]: *** [plugin] Error 1
 cp: libHrscCamera.so: No such file or directory
 gmake[4]: *** [install] Error 1
 The error is completely clear as it is: the build tries to link static
 library libstdc++.so into shared object. This is not supported.

 Thanks, Kostik, for the fast response.
 The error isn't so clear to me, sorry. I thought libstdc++.a is the
 static library and it is taken to be referenced/compiled into a shared
 Linked in.

 object created by the application I try to compile.
 Right, and this is not supported. Code linked into shared object must
 be compiled PIC. An .a library usually does not contain objects compiled
 by PIC, ld just dutifully reported back.


 I'm much more confused now, since I thought the last time I compiled
 that piece of software, I never got any error like that. Well, clang
 fails with some obscure errors on the code itself and I'm unwilling to
 correct them, I'll try the legacy gcc 4.2.1 and will report what's
 happening.

 It might have worked by accident (because libstdc++.a objects referenced
 during the link did not carried unsupported relocations), or, much more
 likely, the build system has changed and started doing stupid things.
 It must not link static libraries into shared objects.

 You should examine why it does this, and fix it. Changing compilers is
 just wasting a time.
 
 
 Hmm, I get a similar error when trying to build lang/gcc46 on recent
 10-CURRENT:
 
 
 [..snip..]
 Making all in include
 gmake[4]: Entering directory
 `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include'
 
 mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch
 /usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc
 -B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++
 -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src
 -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs
 -B/usr/local/x86_64-portbld-freebsd10.0/bin/
 -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem
 /usr/local/x86_64-portbld-freebsd10.0/include -isystem
 /usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header
 -nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing
 -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0
 -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include
 -I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2
 -g -std=gnu++0x
 /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h
 \
 -o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch
 In file included from
 /usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0,
 
  from
 /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100:
 
 

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Andreas Tobler]

On 28.12.11 17:31, Rainer Hurling wrote:

On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote:

On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote:

Am 12/28/11 14:58, schrieb Kostik Belousov:

On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:

Hello out here.

I run into a problem since one of the last portupdates and I do not know
whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
AMD64.

Background:
We use a scientific graphical toolset for planetary research called
ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
couple of weeks ago.
On all of my boxes, I do frequently a portupgrade, so I saw binutils got
bumped up and gcc 4.6 is also getting really frequently changed these days.
After a some portupdates within the last weeks, I just decided to
compile ISIS3 again to keep it fresh and on track, but it won't
compile anymore.

On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
CLANG built) I receive in some subfolders containing sources the
follwoing error:

[...]
  Adding API object [UniqueIOCachingAlgorithm]
  Adding API object [UniversalGroundMap]
  Adding API object [UserInterface]
  Adding API object [VariableLineScanCameraDetectorMap]
  Adding API object [VecFilter]
  Adding API object [WorldMapper]
  Adding API object [iException]
  Adding API object [iString]
  Adding API object [iTime]
Working on Package [mex] (11:30:15)
  Adding API object [HrscCamera]
/usr/local/bin/ld:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake[5]: *** [plugin] Error 1
cp: libHrscCamera.so: No such file or directory
gmake[4]: *** [install] Error 1

The error is completely clear as it is: the build tries to link static
library libstdc++.so into shared object. This is not supported.


Thanks, Kostik, for the fast response.
The error isn't so clear to me, sorry. I thought libstdc++.a is the
static library and it is taken to be referenced/compiled into a shared

Linked in.


object created by the application I try to compile.

Right, and this is not supported. Code linked into shared object must
be compiled PIC. An .a library usually does not contain objects compiled
by PIC, ld just dutifully reported back.



I'm much more confused now, since I thought the last time I compiled
that piece of software, I never got any error like that. Well, clang
fails with some obscure errors on the code itself and I'm unwilling to
correct them, I'll try the legacy gcc 4.2.1 and will report what's
happening.


It might have worked by accident (because libstdc++.a objects referenced
during the link did not carried unsupported relocations), or, much more
likely, the build system has changed and started doing stupid things.
It must not link static libraries into shared objects.

You should examine why it does this, and fix it. Changing compilers is
just wasting a time.



Hmm, I get a similar error when trying to build lang/gcc46 on recent
10-CURRENT:


[..snip..]
Making all in include
gmake[4]: Entering directory
`/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include'
mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch
/usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc
-B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs
-B/usr/local/x86_64-portbld-freebsd10.0/bin/
-B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem
/usr/local/x86_64-portbld-freebsd10.0/include -isystem
/usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header
-nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include
-I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2
-g -std=gnu++0x
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h
\
-o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0,
   from
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100:
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/ratio:133:31:
error: 

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Ed Schouten]

* Rainer Hurling rhur...@gwdg.de, 20111228 17:31:
 error: macro _Static_assert passed 3 arguments, but takes just 2
 In file included from 
 /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0:

Hmmm... This seems to apply to my changes. I will look into this
tomorrow. Thanks for the report!

-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/


pgpgFV4VlXdVC.pgp
Description: PGP signature

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[O. Hartmann]

Am 12/28/11 19:10, schrieb Ed Schouten:
 * Rainer Hurling rhur...@gwdg.de, 20111228 17:31:
 error: macro _Static_assert passed 3 arguments, but takes just 2
 In file included from 
 /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0:
 
 Hmmm... This seems to apply to my changes. I will look into this
 tomorrow. Thanks for the report!
 


Be aware that the error produced by the linker I mentioned in the
initial post occurs on FreeBSD 10 as well as FreeBSD 9.0.

I already filed a PR about the problem of a non compiling lang/gcc46
today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test
puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem.

I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0.

Oliver



signature.asc
Description: OpenPGP digital signature

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Kostik Belousov]

On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote:
 Am 12/28/11 19:10, schrieb Ed Schouten:
  * Rainer Hurling rhur...@gwdg.de, 20111228 17:31:
  error: macro _Static_assert passed 3 arguments, but takes just 2
  In file included from 
  /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0:
  
  Hmmm... This seems to apply to my changes. I will look into this
  tomorrow. Thanks for the report!
  
 
 
 Be aware that the error produced by the linker I mentioned in the
 initial post occurs on FreeBSD 10 as well as FreeBSD 9.0.
 
 I already filed a PR about the problem of a non compiling lang/gcc46
 today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test
 puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem.
 
 I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0.

Obviously, linker error during the compilation of third-party software
has nothing to do with compiler error occuring when building gcc.

Do people ever read the texts of the messages ?


pgpXZQ7ftuzPn.pgp
Description: PGP signature