Opened 17 years ago
Closed 16 years ago
#1290 closed bug (fixed)
Problem compiling on MacOS X
Reported by: | jimmiejams | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Build System | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I'm building on MacOS X 10.4.10, using a disk image formatted with HFS+ with case-sensitivity turned on.
I checked out the development tools as per http://haiku-os.org/documents/dev/getting_linux_developer_tools and the Haiku source code as per http://haiku-os.org/documents/dev/getting_the_source_code (hrev21543). When building the source using gcc4 and the command "jam haiku-vmware-image", I get the following error:
C++ generated/objects/darwin/x86/release/build/libbe/app/Message.o In file included from headers/build/BeOSBuildCompatibility.h:7, from <command line>:1: headers/build/os/support/Errors.h:399:1: warning: "ENOATTR" redefined In file included from /usr/include/errno.h:23, from headers/build/os/support/Errors.h:15, from headers/build/BeOSBuildCompatibility.h:7, from <command line>:1: /usr/include/sys/errno.h:227:1: warning: this is the location of the previous de finition src/build/libbe/app/Message.cpp:28:20: error: malloc.h: No such file or director y headers/build/os/storage/Statable.h:34: warning: 'class BStatable' has virtual f unctions but non-virtual destructor src/build/libbe/app/Message.cpp: In member function 'void BMessage::_PrintToStre am(const char*) const': src/build/libbe/app/Message.cpp:429: warning: format '%ld' expects type 'long in t', but argument 2 has type 'dev_t' src/build/libbe/app/Message.cpp:429: warning: format '%lld' expects type 'long l ong int', but argument 3 has type 'ino_t' c++ -c "src/build/libbe/app/Message.cpp" -O -Wall -Wno-ctor-dtor-privacy -Woverl oaded-virtual -Wpointer-arith -Wcast-align -Wsign-compare -Wno-multichar -D_ZETA _USING_DEPRECATED_API_=1 -D_ZETA_TS_FIND_DIR_=1 -fPIC -include BeOSBuildCompatib ility.h -DARCH_x86 -D_NO_INLINE_ASM -D__INTEL__ -D_GNU_SOURCE -D_FILE_OFFSET_BIT S=64 -DHAIKU_HOST_PLATFORM_DARWIN -iquote src/build/libbe/app -iquote generated/ objects/common/build/libbe/app -iquote generated/objects/darwin/x86/common/build /libbe/app -iquote generated/objects/haiku/x86/common/build/libbe/app -I headers /build/private/app -I headers/build/private/shared -I headers/build/host/darwin -I headers/build -I headers/build/os -I headers/build/os/app -I headers/build/os /drivers -I headers/build/os/kernel -I headers/build/os/interface -I headers/bui ld/os/storage -I headers/build/os/support -o "generated/objects/darwin/x86/relea se/build/libbe/app/Message.o" ; ...failed C++ generated/objects/darwin/x86/release/build/libbe/app/Message.o ...
Backing out to hrev21514 fixes this. However, I then get this error:
C++ generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader.o src/tools/vmdkheader/vmdkheader.cpp: In function 'int main(int, char**)': src/tools/vmdkheader/vmdkheader.cpp:41: warning: format '%u' expects type 'unsig ned int', but argument 3 has type 'long unsigned int' src/tools/vmdkheader/vmdkheader.cpp:100: warning: format '%u' expects type 'unsi gned int', but argument 3 has type 'long unsigned int' Link generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status cc -o "generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader" "gen erated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader.o" -lgcc_s.1 ; ...failed Link generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader ...
Change History (4)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Yep, hrev21546 fixed it for me, thanks.
The second problem like it might be because vmdkheader is compiled using 'c++' but linked using 'cc'
c++ -c "src/tools/vmdkheader/vmdkheader.cpp" -O -Wall -Wno-ctor-dtor-privacy -Wo verloaded-virtual -Wpointer-arith -Wcast-align -Wsign-compare -Wno-multichar -D_ ZETA_USING_DEPRECATED_API_=1 -D_ZETA_TS_FIND_DIR_=1 -DARCH_x86 -D_NO_INLINE_ASM -D__INTEL__ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DHAIKU_HOST_PLATFORM_DARWIN -i quote src/tools/vmdkheader -iquote generated/objects/common/tools/vmdkheader -iq uote generated/objects/darwin/x86/common/tools/vmdkheader -iquote generated/obje cts/haiku/x86/common/tools/vmdkheader -I headers/private/kernel -I headers/build /host/darwin -o "generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheade r.o" ; src/tools/vmdkheader/vmdkheader.cpp: In function 'int main(int, char**)': src/tools/vmdkheader/vmdkheader.cpp:41: warning: format '%u' expects type 'unsig ned int', but argument 3 has type 'long unsigned int' src/tools/vmdkheader/vmdkheader.cpp:100: warning: format '%u' expects type 'unsi gned int', but argument 3 has type 'long unsigned int' cc -o "generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader" "gen erated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader.o" -lgcc_s.1 ; /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status
I verified this by running the following command
jams:/Volumes/haiku-work/haiku:$ c++ -o generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader generated/objects/darwin/x86/release/tools/vmdkheader/vmdkheader.o
And this linked fine. Then running jam haiku-vmware-image
again built generated/haiku.vmdk
without a hitch. Unfortunately I'm no expert on jam, so I couldn't figure out how to fix this properly, but at least I know one way to fix it.
comment:3 by , 17 years ago
Component: | - General → Build System |
---|---|
Owner: | changed from | to
comment:4 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should have been fixed quite a while ago. Please reopen, if any problem still persists.
hrev21546 should fix the first issue.
Regarding the missing ___gxx_personality_v0, I don't know. Maybe it's defined in another library. Though AFAIK, we have not changed what libraries we link against since Morgan Howe finished porting the build system to MacOS X. Some Google hits suggest that it might be a gcc version problem, e.g. if you build a library with one gcc version and then an executable that links against the library with another gcc version. But since only the gcc library is involved in this case, this seems unlikely.
You could check which library the symbol lives in. Not sure how that is done best on MacOS X. On other platforms I'd iterate through the existing libraries and do a
"nm <library> | grep ___gxx_personality_v0"
. Maybe that works too.