Apache OpenOffice (AOO) Bugzilla – Issue 38161
transex3 build break GetEnv(char const*) undefined
Last modified: 2005-01-11 20:57:33 UTC
SRC680_m63 Mac OS X port build on Mac OS X 10.3.4 / XCode 1.5 / gcc-3.3 transex build's breaks like following ld: Undefined symbols: GetEnv(char const*) SourceDirectory::GetFullPath() SourceDirectory::CreateRootDirectory(ByteString const&, ByteString const&, unsigned char) SourceDirectory::~SourceDirectory() dmake: Error code 1, while making '../unxmacxp.pro/bin/transex3' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /Users/ericb/Desktop/OpenOffice.org680/transex3/source This issue is already described in #i17662# , but the Pavel Janik's proposed patch is more simple in comparizon of the one proposed in #i17662#. While Pavel verify it's availability in every arch, this patch is only a workaround for the Mac OS X build. ASAP, if no problem occurs with other archs, it will probably integrated in 680. -- ericb
Created attachment 19931 [details] patch for transex3/source/makefile in Mac OS X build for SRC680
.
ause: can this changed order of libs affect other systems? /me still have to build on all his systems to verify.
Successfull build on GNU/Linux/x86 with gcc-3.4.1, Microsoft Windows 2003 with .NET 2003 and Solaris/SPARC with CC: Sun C++ 5.5 2003/03/12. So it should not break and helps MacOS X ;-)
Reasoning for this patch is here: http://developer.apple.com/documentation/DeveloperTools/Conceptual/Build_System/Linking/Linking.html --- cut here --- Placing static libraries after dynamic libraries in the Frameworks & Libraries build phase, ensures that the static linker binds references to external symbols defined in static libraries at build time, even when newer versions of the static libraries the application originally was linked with are present in the user’s system. When static libraries are listed before a dynamic library in the Frameworks & Libraries build phase, the static linker doesn’t resolve references to symbols in those static libraries. Instead, those symbols are resolved by the dynamic linker at runtime. This may cause problems when the static libraries are updated, as the application links to the new, potentially incompatible versions of the symbols instead of the ones the developer intended. --- cut here --- My patch only moves static bootstrap library after the first shared library. Maybe I should move it at the end?
Hi Pavel, This doc is very complete and explain a lot of things, and this is probably the cleanest fix in the list : we are completely sure of what we do :-) Then, I think it's probably too a good idea to move $(BTSTRPLIB) at the end of the list. I've planed to begin a clean m64 build tonight, and I'll test this on Mac OS X. Of course, this test must be completed with others in others archs. To be continued...
I have solved it in the less invasive way: I have copied 1.1.4's makefile's magic to pj15. See attached patch transex3.diff.
Created attachment 20988 [details] patch from pj15
Verified in my local builds.
closing.