Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/crystal/scm/crystal: SubversionException: ("Expected FS format between '1' and '3'; found format '4'", 160043)). Look in the Trac log for more information.

Ticket #355 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

sprcal3d fails to link on ubuntu with gcc 4.1.2

Reported by: dave.bentham@… Owned by: sunshine
Priority: minor Milestone: Version 1.4 pre1
Component: build system Version: V1.1
Keywords: sprcal3d fpic visibility hidden Cc:

Description (last modified by sunshine) (diff)

Reproduced from CS-forum:1359

Hi, Ive been building CS on Ubuntu Edgy for some time for the Planeshift game.

But then I did the Ubuntu online upgrade to Feisty Fawn, and now I cannot build CS (r26888) plugins, as the link fails as follows. I am not familiar with the CS code; I just kinda expected it all to just work after the upgrade. Any ideas? Thanks, Dave

LinkPlugin sprcal3d.so
./out/linux/debug/plugins/mesh/sprcal3d/object/sprcal3d.o: In function `CS::Plugin::SprCal3d::csCal3dSkeletonBone::Initialize()':
/home/dave/projects/planeshift-dev/cs/plugins/mesh/sprcal3d/object/sprcal3d.cpp:2411: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str() const'
/usr/bin/ld: ./out/linux/debug/plugins/mesh/sprcal3d/object/sprcal3d.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str() const' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

    g++ -Wl,--as-needed -o sprcal3d.so ./out/linux/debug/plugins/mesh/sprcal3d/object/sprcal3d.o  -lm -ldl -lnsl -L/usr/local/lib -Wl,-z,defs -Wl,--warn-unresolved-symbols -Wl,-E -g3 -shared ./out/linux/debug/libs/libcrystalspace-1.1.a -lpthread -lpthread -lz -L/home/dave/projects/planeshift-dev/cal3d/lib -lcal3d -lm -ldl -lnsl -L/usr/local/lib -Wl,-z,defs -Wl,--warn-unresolved-symbols -Wl,-E -g3 \
      -Wl,-soname,sprcal3d.so
 
...failed LinkPlugin sprcal3d.so ...

btw, its the 64-bit version, gcc 4.1.2.

A work around seems to be:

Removing the following from Jamconfig helps...

COMPILER.C++FLAGS += "-fvisibility-inlines-hidden" ;
COMPILER.CFLAGS += "-fvisibility=hidden" ;

I dont know if thats the correct solution, but it works for me.

Attachments

config.log Download (266.8 KB) - added by dave.bentham@… 7 years ago.
config.log

Change History

  Changed 7 years ago by sunshine

  • priority changed from minor to major
  • description modified (diff)

  Changed 7 years ago by sunshine

  • keywords sprcal3d fpic visibility hidden added
  • reporter changed from jorrit to dave.bentham@…

  Changed 7 years ago by sunshine

See also related ticket #333.

follow-up: ↓ 6   Changed 7 years ago by res

  Changed 7 years ago by res

Dave: is it possible to see config.log?

Changed 7 years ago by dave.bentham@…

config.log

in reply to: ↑ 4   Changed 7 years ago by sunshine

Replying to res:

This is interesting:  https://bugs.launchpad.net/ubuntu/+source/gcc-4.1/+bug/109262

My original implementation of this check incorporated the std::string anomaly in order to detect this bug. Unfortunately, practical experience showed that the std::string test was not reliable. There were cases where "inlines hidden" visibility appeared to succeed with std::string, but then failed in actual use in CS.

follow-up: ↓ 8   Changed 7 years ago by res

It seems that the issue reports usually affect plugins. So maybe the test should incorporate the creation of a shared library.

in reply to: ↑ 7 ; follow-up: ↓ 9   Changed 7 years ago by sunshine

Replying to res:

It seems that the issue reports usually affect plugins. So maybe the test should incorporate the creation of a shared library.

That's pretty difficult to do well /properly / cleanly since plugin-creation logic is buried in the Jam build system. The configure script doesn't really have knowledge of it, and, of course, the Jam build system isn't yet configured at the time the configure script is running. It's sort of a chicken-and-egg issue.

I somewhat favor the ham-handed approach of just disabling the flags altogether for compilers / architectures which have proven faulty. It's not elegant, but it is simple to understand and maintain. We seem to know, for instance, that the problem crops up regularly on x86_64 platforms with gcc 3.4.x and 4.1.x.

in reply to: ↑ 8 ; follow-up: ↓ 10   Changed 7 years ago by res

Replying to sunshine:

That's pretty difficult to do well /properly / cleanly since plugin-creation logic is buried in the Jam build system. The configure script doesn't really have knowledge of it, and, of course, the Jam build system isn't yet configured at the time the configure script is running. It's sort of a chicken-and-egg issue.

Well, maybe don't build a plugin the exact same way as Jam would... my suspicion is that any shared library would exhibit the issues. So perhaps just pass some probably problematic flags (-shared, -fPIC [as detected by configure of course]) to CS_CHECK_BUILD?

I somewhat favor the ham-handed approach of just disabling the flags altogether for compilers / architectures which have proven faulty. It's not elegant, but it is simple to understand and maintain. We seem to know, for instance, that the problem crops up regularly on x86_64 platforms with gcc 3.4.x and 4.1.x.

It also seems that now problems cropped up with certain compiler/platform/*distribution* combinations - exemplified by the problems occuring on ubuntu but not other distros with the same combination of platform and compiler. Knocking out a feature for a wide range of systems because one distro messed up seems wasteful.

in reply to: ↑ 9   Changed 7 years ago by sunshine

Replying to res:

Well, maybe don't build a plugin the exact same way as Jam would... my suspicion is that any shared library would exhibit the issues. So perhaps just pass some probably problematic flags (-shared, -fPIC [as detected by configure of course]) to CS_CHECK_BUILD?

That's precisely how my original std::string test worked. It applied all flags: "visibility hidden", -shared, and -fPIC, yet it was still unreliable.

It also seems that now problems cropped up with certain compiler/platform/*distribution* combinations - exemplified by the problems occuring on ubuntu but not other distros with the same combination of platform and compiler. Knocking out a feature for a wide range of systems because one distro messed up seems wasteful.

All cases I recall were on 64-bit platforms using gcc 3.4.x and gcc 4.1.x. There had been some reports that 4.1.2 fixed the issue for some people, but others had reported that it did not. gcc 4.2, on the other hand, is supposed to have fixed the problem for "real".

follow-up: ↓ 12   Changed 7 years ago by res

The problem is actually that r26888 has a flawed "-fvisibility-inlines-hidden is buggy" check. The test was changed to the flawed one in r26865, but changed back again in r26932. Hence I'm tempted to resolve this issue as "invalid".

in reply to: ↑ 11   Changed 7 years ago by sunshine

Replying to res:

The problem is actually that r26888 has a flawed "-fvisibility-inlines-hidden is buggy" check. The test was changed to the flawed one in r26865, but changed back again in r26932. Hence I'm tempted to resolve this issue as "invalid".

Dave Bentham, please recheck this issue using r26932 or later. Be sure to perform jam distclean, followed by configure, and jam.

  Changed 7 years ago by dave.bentham@…

Done that - I get the same link failure (FYI, I did a clean checkout & build):

LinkPlugin sprcal3d.so ./out/linux/debug/plugins/mesh/sprcal3d/object/sprcal3d.o: In function `CS::Plugin::SprCal3d::csCal3dSkeletonBone::Initialize()': /home/dave/projects/planeshift-dev/cs/plugins/mesh/sprcal3d/object/sprcal3d.cpp:2412: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str() const' /usr/bin/ld: ./out/linux/debug/plugins/mesh/sprcal3d/object/sprcal3d.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str() const' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status

g++ -Wl,--as-needed -o sprcal3d.so ./out/linux/debug/plugins/mesh/sprcal3d/object/sprcal3d.o -lm -ldl -lnsl -L/usr/local/lib -Wl,-z,defs -Wl,--warn-unresolved-symbols -Wl,-E -g3 -shared ./out/linux/debug/libs/libcrystalspace-1.1.a -lpthread -lpthread -lz -L/home/dave/projects/planeshift-dev/cal3d/lib -lcal3d -lm -ldl -lnsl -L/usr/local/lib -Wl,-z,defs -Wl,--warn-unresolved-symbols -Wl,-E -g3 \

-Wl,-soname,sprcal3d.so

...failed LinkPlugin sprcal3d.so ... ...failed updating 1 target(s)...

  Changed 7 years ago by rolenun

This is not a CS error. This is a gcc bug. The bug affects CS, CEL, and PS during the linker stage of compiling. Setting the value by using: export CXXFLAGS='-ggdb3 -O' before using the ./configure command for CS or CEL does fix the gcc bug. This bug does not exist in version 4.1.1 or 4.1.3 of gcc. This error occurs when trying to build CS or CEL using --enable-debug in Ubuntu Feisty (7.04) using GCC 4.1.2

  Changed 7 years ago by vknecht

  • milestone changed from Version 1.2 pre1 to Version 1.2 RC2

  Changed 7 years ago by jorrit

  • priority changed from major to minor
  • milestone changed from Version 1.2 RC2 to Version 1.4 pre1

  Changed 7 years ago by sunshine

Marten and I both confirm this problem with g++ 4.1.3 on 32-bit Ubuntu/Kubuntu 7.10.

  Changed 7 years ago by sunshine

  • owner changed from admin to sunshine
  • status changed from new to assigned

  Changed 7 years ago by sunshine

  • status changed from assigned to closed
  • resolution set to fixed

Resolved (hopefully) for most cases by r28306 and r28307.

  Changed 7 years ago by sunshine

Also see #478 for resolution involving rebuilding binutils to use -fPIC.

Note: See TracTickets for help on using tickets.