[MacPorts] #47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes -----------------------------+-------------------------------- Reporter: tobias.netzel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: ld64 -----------------------------+-------------------------------- (I'm using OS X 10.5 PowerPC.) The WebCore framework, when linked using ld64-127 causes crashes when trying to launch an executable that uses it.[[BR]] Linking itself works without errors or warnings.[[BR]] When using ld64-97 for linking the very same object files I don't get any crashes.[[BR]] Now WebCore is quite huge, some 40 MB in release build with debug symbols.[[BR]] Any suggestions where to look at in order to maybe fix this issue? The other (much smaller) frameworks like JavaScriptCore and WebKit(Legacy) do work when linked using ld64-127.[[BR]] However, when launching in gdb, for every framework linked with ld64-127 I see the following two messages: {{{ unable to read unknown load command 0x24 unable to read unknown load command 0x26 }}} -- Ticket URL: <https://trac.macports.org/ticket/47157> MacPorts <https://www.macports.org/> Ports system for OS X
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes ------------------------------+------------------------ Reporter: tobias.netzel@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ld64 | ------------------------------+------------------------ Changes (by larryv@…): * owner: macports-tickets@… => jeremyhu@… -- Ticket URL: <https://trac.macports.org/ticket/47157#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes ------------------------------+------------------------ Reporter: tobias.netzel@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ld64 | ------------------------------+------------------------ Comment (by jeremyhu@…): That just means that your gdb is using a libmacho that does not know about whatever those load commands are. You can run 'otool -l /path/to/macho' to see what they are (note you should of course be using otool from MacPorts' cctools port in this case). -- Ticket URL: <https://trac.macports.org/ticket/47157#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes ------------------------------+------------------------ Reporter: tobias.netzel@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ld64 | ------------------------------+------------------------ Comment (by jeremyhu@…): What are the crashe? Can you attach logs that might shed some light? -- Ticket URL: <https://trac.macports.org/ticket/47157#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes ------------------------------+------------------------ Reporter: tobias.netzel@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ld64 | ------------------------------+------------------------ Comment (by tobias.netzel@…): Replying to [comment:3 jeremyhu@…]:
What are the crashe? Can you attach logs that might shed some light? The crash seems to be a null pointer deref in the destructor of a C++-object, compiled from an Objective-C++ source file. But the backtrace indicates that the stack got completely corrupted, so I don't consider the resulting crash location of any use in finding the cause for this issue. I guess one would have to debug the library loading process - provided there's no other way to analyze the linker output.
-- Ticket URL: <https://trac.macports.org/ticket/47157#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes ------------------------------+------------------------ Reporter: tobias.netzel@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ld64 | ------------------------------+------------------------ Comment (by jeremyhu@…): I'd use 'otool -l' to compare the load commands between the two versions and 'otool -t -v' to disassemble the text segment and compare that way. Maybe something will stick out. -- Ticket URL: <https://trac.macports.org/ticket/47157#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
#47157: ld64 @2_0 +ld64_127 Linked huge PowerPC dynamic library causes crashes ------------------------------+------------------------ Reporter: tobias.netzel@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ld64 | ------------------------------+------------------------ Comment (by tobias.netzel@…): I attached the output of otool -lv on JavaScriptCore and WebCore, linked with both ld64-97 and ld64-127 each.[[BR]] JavaScriptCore seems to work OK when linked with both linkers, but WebCore linked with ld64-127 doesn't.[[BR]] There are some differences; do you see something that's obviously wrong? -- Ticket URL: <https://trac.macports.org/ticket/47157#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts