Exactly. I'm running into this problem with OOo1.9 and required libraries. It is very interesting when the ./configure file cannot find a header file in the appropriate directory (/usr/include). That is what I consider a serious bug.
This is why porting work is so tedious. What works on Linux (i.e. what most OOo developers are using) doesn't necessarily work on Mac OS X since Apple likes to "think different" put things in different places than most other Unix platforms.
jjmckenzie51 wrote:
That one really gets me. Why can't you name the new function with a new name? It is not that hard.
In theory, it is easy. However, in projects like OOo, many open source projects are pulled in and since those projects were probably developed in Linux or Windows, it is easy to see how simple function names can exist in an open source project and Mac OS X. More often than not, the duplicate symbols are for the software package but the OS has a different version of the library and OOo depends on one specific version. This seems to happen a lot with the STL.
jjmckenzie51 wrote:
I'm not offended. I just stating that I'm having problems building one of the required packages to build OOo/NeoJ. It is definately NOT a c/C++/Java/Python code problem, but just a plain old script error. This is what bothers me.
But remember, you and Ed are the only ones who are trying to compile OOo 1.1.4 on Tiger. I don't think it is realistic to expect Linux and Windows developers to accurately guess what is different on your platform especially when your platform is not that the OOo site supports.
I'll leave that decision up to Ed. Right now I'm working on the basic files needed to build OOo. I think that I found a workaround for one of them, that might end up being a patch for the gnome package.
jjmckenzie51 wrote:
BTW, if you want I can e-mail you off of the list with the problem I have and see what you think about it. As I said, it is a basic script fault and that is very frustrating. And this one is definately not Sun's or the OO project's fault.
I would suggest that you create a "building on Tiger" topic in the NeoOffice/J Development forum so that you and Ed can your Tiger build issues as I do not have a Tiger machine and so guessing at what is different in Tiger is not going to be a good use of either of our time. Ed has been trying to compile on Tiger and has already committed and STL fix for the OOo code about a week ago.
[/quote]
Again, I will leave this up to Ed. Maybe we can get things going. BTW, there is an IZ for building 1.1.5 on Tiger with gcc 4.0. The major problem is that gcc 4.0 wants explict declaration of functions. Hopefully, this will help with building 1.1.4 with gcc 3.3 on Tiger.
Thank you and the other folks on the forums for understanding what happens when Apple decides to 'upgrade' their OS.
BTW, the same thing happened when the Linux community decided to move from the 2.4 kernel series to the 2.6 series.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jun 16, 2005 10:30 pm Post subject:
FWIW, I am working on Tiger builds for 1.1.4 for NeoJ. You are right; it does not work out of the box. Since Patrick and I have been building NeoJ on 10.2 and I only did X11 on 10.3, I never have done a full build on 10.4. Doing individual modules worked on 10.4, but a full build failed and was something I hadn't started working on until a few weeks ago.
The basic support for stlport is in, but I am not personally focusing on gcc 4 yet. I'm just trying to get it working on gcc 3 for now.
Presently I'm debugging a build failure that is actually a segfault in the rscdep utility that's built as part of the compile phase. I've been sidetracked due to a friend's wedding and haven't been able to make much progress as of yet, but it's a new failure. I just finished rebuilding rscdep a few days ago with debug symbols. It's failing in an allocator, but it's pretty bizarre and reading the source doesn't bring forth anything obvious.
FWIW, I am working on Tiger builds for 1.1.4 for NeoJ. You are right; it does not work out of the box. Since Patrick and I have been building NeoJ on 10.2 and I only did X11 on 10.3, I never have done a full build on 10.4. Doing individual modules worked on 10.4, but a full build failed and was something I hadn't started working on until a few weeks ago.
That was part of the point I was trying to make. If you upgrade your OS, you should not have to 'jump through hoops' to make code work.
[quote="OPENSTEP"]The basic support for stlport is in, but I am not personally focusing on gcc 4 yet. I'm just trying to get it working on gcc 3 for now.
Quote:
Actually, I had no problems with stlport once I applied the patches available at OOo. I had MAJOR problems building udkapi (it got to the first sub-program in the package and stopped.) This was after rebuilding every package in OOo 1.1.4. This was and continues to 'not be fun'.
[quote="OPENSTEP"]Presently I'm debugging a build failure that is actually a segfault in the rscdep utility that's built as part of the compile phase. I've been sidetracked due to a friend's wedding and haven't been able to make much progress as of yet, but it's a new failure. I just finished rebuilding rscdep a few days ago with debug symbols. It's failing in an allocator, but it's pretty bizarre and reading the source doesn't bring forth anything obvious.
I was getting segfaults in idlc. I could not figure out why.
Maybe you could advise what you did to get around the problems in idlc, if you had any.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jun 17, 2005 9:20 am Post subject:
Unfortunately, it's pretty much a given that a major OS upgrade is going to require fixes to get OOo to compile successfully. It's been the case for 10.2 -> 10.3 and now 10.3 -> 10.4. The problem isn't so much the OS update, but rather that the headers keep changing (e.g. 10.2 doesn't have wchar_t, 10.3 does, 10.4 changes some headers to use include_next, etc.) and the standard libraries too. It makes things painful for sure, mostly in STLport and in what the link lines need to include.
The rscdep crash is different though; I'm not precisely sure what its cause is. I haven't seen the idlc crash yet. When it's crashing on you, can you copy the command line and send it over? The next step would be to rebuild idlc with debug symbols and then run that individual command again to produce the crash and start debugging. That's what I'm doing for rscdep though with my friend's wedding it's been sitting in an open debgger for a while
Unfortunately, it's pretty much a given that a major OS upgrade is going to require fixes to get OOo to compile successfully. It's been the case for 10.2 -> 10.3 and now 10.3 -> 10.4. The problem isn't so much the OS update, but rather that the headers keep changing (e.g. 10.2 doesn't have wchar_t, 10.3 does, 10.4 changes some headers to use include_next, etc.) and the standard libraries too. It makes things painful for sure, mostly in STLport and in what the link lines need to include.
It would not build in Panther (10.3.4-10.3.9) either. I'm wondering if I have setup something wrong. I can send through to you the contents of my Macosx.Env.sh file (I am building in bash, but it calls tsch sessions.)
OPENSTEP wrote:
The rscdep crash is different though; I'm not precisely sure what its cause is. I haven't seen the idlc crash yet. When it's crashing on you, can you copy the command line and send it over? The next step would be to rebuild idlc with debug symbols and then run that individual command again to produce the crash and start debugging. That's what I'm doing for rscdep though with my friend's wedding it's been sitting in an open debgger for a while
Enjoy the wedding. I guess I could rebuild idlc with debug (build -debug) and then run the next command. Again, if you want, I can run build -v > messages 2> errors and send you both files. The udkapi build dies on the first gdl file that needs to be built.
ericb did a 10.4-only build of 1.1.4 to replace the 1.1.4 build of his that won't run on 10.4 (and which led streams of people to the OOo support forum here, and to lots of postings on the web about OOo being incompatible with 10.4 ), so in theory it should be possible....
OTOH, I think all the folks on dev@porting fink or darwinports or whatever everything, unlike you and Patrick and Terry (But then Neo/J and the official OOo 1.1.2 build didn't have problems running on 10.4, either )
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jun 17, 2005 8:36 pm Post subject:
jjmckenzie51 wrote:
It would not build in Panther (10.3.4-10.3.9) either. I'm wondering if I have setup something wrong. I can send through to you the contents of my Macosx.Env.sh file (I am building in bash, but it calls tsch sessions.)
Hmm...that's bizarre. I was definitely able to get things going on 10.3 with the build since that's what I used to use. It's only been 10.4 that's been a problem. Please send me along your MacosxEnv file and, if possible, any crashlogs you have from idlc. I definitely can get past the udkapi module, so something's amiss.
Oh, another hint that may not be obvious from the get to...are you trying to build in a directory whose path contains no spaces? That is, neither the hard drive name nor any folders leading to it? If you are I'd highly recommend you not. Spaces are rather uncommon in the Unix world since they're a pain in the neck to type on a command line Most makefile based apps can't handle them properly. Heck, not even XCode handles them right!
It would not build in Panther (10.3.4-10.3.9) either. I'm wondering if I have setup something wrong. I can send through to you the contents of my Macosx.Env.sh file (I am building in bash, but it calls tsch sessions.)
Hmm...that's bizarre. I was definitely able to get things going on 10.3 with the build since that's what I used to use. It's only been 10.4 that's been a problem. Please send me along your MacosxEnv file and, if possible, any crashlogs you have from idlc. I definitely can get past the udkapi module, so something's amiss.
Oh, another hint that may not be obvious from the get to...are you trying to build in a directory whose path contains no spaces? That is, neither the hard drive name nor any folders leading to it? If you are I'd highly recommend you not. Spaces are rather uncommon in the Unix world since they're a pain in the neck to type on a command line Most makefile based apps can't handle them properly. Heck, not even XCode handles them right!
Ed:
No spaces in the directory:
/Users/jamesmckenzie/NeoOfficeBuild/neojava/build (I used Patrick's install instructions and I've worked with UNIX/Linuxes for quite some time now.)
Maybe the problem is that I'm trying to build in bash rather than tsch (I don't like C shells for a varity of reasons)?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jun 17, 2005 10:06 pm Post subject:
I doubt it...most all of the scripts that require a specific shell are OK. As long as the manual "setenv foo bar" commands you type get translated to bash, you should be fine. The rest of the build system should be unaffected. That said, I've never tried building from bash (I'm a csh guy).
I doubt it...most all of the scripts that require a specific shell are OK. As long as the manual "setenv foo bar" commands you type get translated to bash, you should be fine. The rest of the build system should be unaffected. That said, I've never tried building from bash (I'm a csh guy).
Ed:
I think that I found the problem in the checkdll.sh file:
If I run the following command:
checkdll.sh libvcl680mxp.dylib
this works as it should.
If I run the following command:
checkdll.sh -L /usr/lib libvcl680mxp.dylib
I get an error in a dylib that is in the /usr/lib directory, not the libvcl680.dylib file that should be checked.
If I run the checkdll.sh program against the 'bad' dylib file, it errors as it should but with a different error than the check for libvcl680mxp.dylib.
So, is the checkdll.sh script working 'as designed' and is supposed to check every file in the library directories inputted to it?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jun 17, 2005 11:28 pm Post subject:
Dammit, this rscdep bug is a stack smasher. The count is being fubared by malloc (!) wtf?
I've been staring at this for hours now and have to start packing but figured I'd leave the gdb log here. The crash is happening when the second ".." is being added in a path that is of the form "../../foo/bar" (notice the -fp argument on the command line):
Code:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Volumes/abyss/neoj11/neojava/build/solver/645/unxmacxp.pro/bin/rscdep -CHARSET_DONTKNOW -s -I. -I -I../inc -I../../inc -I../../unxmacxp.pro/inc -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DSOLAR_JAVA -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" -fp../../unxmacxp.pro/srs/dbwizres.srs dbwizres.src
Breakpoint 1, DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2496
2496 for ( nPos = 0;
(gdb) b contnr.cxx:230
Breakpoint 4 at 0x10318e4: file /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx, line 230.
(gdb) c
Continuing.
Breakpoint 4, CBlock::Insert (this=0x160eed0, p=0x160ee90, nIndex=0, nReSize=16) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:230
230 if ( nCount == nSize )
(gdb) n
257 if ( nIndex < nCount )
(gdb) print *this
$37 = {
pPrev = 0x0,
pNext = 0x0,
nSize = 16,
nCount = 0,
pNodes = 0x160f720
}
(gdb) n
266 pNodes[nIndex] = p;
(gdb)
267 nCount++;
(gdb) print *this
$38 = {
pPrev = 0x0,
pNext = 0x0,
nSize = 16,
nCount = 0,
pNodes = 0x160f720
}
(gdb) n
268 }
(gdb) print *this
$39 = {
pPrev = 0x0,
pNext = 0x0,
nSize = 16,
nCount = 1,
pNodes = 0x160f720
}
(gdb) bt
#0 CBlock::Insert (this=0x160eed0, p=0x160ee90, nIndex=0, nReSize=16) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:268
#1 0x01032e94 in Container::ImpInsert (this=0xbfffbea0, p=0x160ee90, pBlock=0x0, nIndex=0) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:817
#2 0x010331cc in Container::Insert (this=0xbfffbea0, p=0x160ee90, nIndex=4294967295) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:912
#3 0x010d45f4 in DirEntryStack::Push (this=0xbfffbea0, pEntry=0x160ee90) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:337
#4 0x0105bc14 in DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2534
#5 0x010560b8 in DirEntry::ImpParseName (this=0xbfffc410, rbInitName=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:707
#6 0x01056d7c in DirEntry::DirEntry (this=0xbfffc410, rInitName=@0xbfffc3f0, eStyle=FSYS_STYLE_HOST) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:959
#7 0x010569cc in DirEntry::DirEntry (this=0xbfffc410, rInitName=@0xbfffc3f0, eStyle=FSYS_STYLE_HOST) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:913
#8 0x00002df8 in main (argc=22, argv=0xbfffc6d4) at /Volumes/abyss/neoj11/neojava/build/tools/bootstrp/rscdep.cxx:147
(gdb) help watch
Set a watchpoint for an expression.
A watchpoint stops execution of your program whenever the value of
an expression changes.
(gdb) this
Undefined command: "this". Try "help".
(gdb) print thi
No symbol "thi" in current context.
(gdb) print this
$40 = (CBlock * const) 0x160eed0
(gdb) print *this
$41 = {
pPrev = 0x0,
pNext = 0x0,
nSize = 16,
nCount = 1,
pNodes = 0x160f720
}
(gdb) print &(this->nCount)
$42 = (USHORT *) 0x160eeda
(gdb) watch *((USHORT *)0x160eeda)
Hardware watchpoint 5: *(USHORT *) 23129818
(gdb) c
Continuing.
Breakpoint 1, DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2496
2496 for ( nPos = 0;
(gdb) n
2502 if ( nPos == 0 && aPfad.Len() > 0 && ( aPfad.GetChar(0) == '/' ) )
(gdb) c
Continuing.
Hardware watchpoint 5: *(USHORT *) 23129818
Old value = 1
New value = 60688
0x90003ed8 in szone_malloc ()
(gdb) bt
#0 0x90003ed8 in szone_malloc ()
#1 0x90003a5c in malloc_zone_malloc ()
#2 0x900039c0 in malloc ()
#3 0x010ac6c0 in operator new () at /Volumes/abyss/neoj11/neojava/build/tools/source/inet/inetstrm.cxx:1878
#4 0x0105bbd0 in DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2534
#5 0x010560b8 in DirEntry::ImpParseName (this=0xbfffc410, rbInitName=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:707
#6 0x01056d7c in DirEntry::DirEntry (this=0xbfffc410, rInitName=@0xbfffc3f0, eStyle=FSYS_STYLE_HOST) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:959
#7 0x010569cc in DirEntry::DirEntry (this=0xbfffc410, rInitName=@0xbfffc3f0, eStyle=FSYS_STYLE_HOST) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:913
#8 0x00002df8 in main (argc=22, argv=0xbfffc6d4) at /Volumes/abyss/neoj11/neojava/build/tools/bootstrp/rscdep.cxx:147
(gdb)
I doubt it...most all of the scripts that require a specific shell are OK. As long as the manual "setenv foo bar" commands you type get translated to bash, you should be fine. The rest of the build system should be unaffected. That said, I've never tried building from bash (I'm a csh guy).
Ed:
I think that I found the problem in the checkdll.sh file:
If I run the following command:
checkdll.sh libvcl680mxp.dylib
this works as it should.
If I run the following command:
checkdll.sh -L /usr/lib libvcl680mxp.dylib
I get an error in a dylib that is in the /usr/lib directory, not the libvcl680.dylib file that should be checked.
If I run the checkdll.sh program against the 'bad' dylib file, it errors as it should but with a different error than the check for libvcl680mxp.dylib.
So, is the checkdll.sh script working 'as designed' and is supposed to check every file in the library directories inputted to it?
After quite a long time rebuilding libjpeg, and the use of Maho's script, I successfully built eleven different versions of OOo1.9 Milestone 110. I'm going to move back to building Neo/J with OOo 1.1.4. I could not build OOo 1.1.4 as it stopped at udkapi, but I think this was because I was trying to build in a bash shell, and OOo might need to be built in a continuous tcsh session.
After quite a long time rebuilding libjpeg, and the use of Maho's script, I successfully built eleven different versions of OOo1.9 Milestone 110. I'm going to move back to building Neo/J with OOo 1.1.4. I could not build OOo 1.1.4 as it stopped at udkapi, but I think this was because I was trying to build in a bash shell, and OOo might need to be built in a continuous tcsh session.
Congrats on getting 110 to build!
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
After quite a long time rebuilding libjpeg, and the use of Maho's script, I successfully built eleven different versions of OOo1.9 Milestone 110. I'm going to move back to building Neo/J with OOo 1.1.4. I could not build OOo 1.1.4 as it stopped at udkapi, but I think this was because I was trying to build in a bash shell, and OOo might need to be built in a continuous tcsh session.
Congrats on getting 110 to build!
Thank you. I used Maho's scripts. I manually Fink'd the packages he recommended. However, 1.1.4 still will not build past idlc. I'm going to compare the code between 1.9 M110 and 1.1.4 for that package. It may be what I need to finally build Neo/J on Tiger. I might get SRX645_m57 to see if it will build, too.
Update: I copied idlc and two required libraries (dylib) files from OOo1.9_m110 to 1.1.4 and idlc still segfaults with an error 138. This is quite interesting. I think something is missing, but I don't know what. Eric Hoch or Eric Bachard built 1.1.4 on Tiger. I guess I will have to look into what they did or did not do.
At the present time, I'm retrieving m56 (m57 was not available) and I will try to build it.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jun 30, 2005 12:36 am Post subject:
Just an update...I still have been absolutely unable to track this biatch down. The system memory allocator is where the memory overwrite is occurring. The crash happens when rscdep is attempting to parse a path of the form "../..", e.g. pushing two "parent" entries onto the directory path stack. In between the two breakpoints at these directory puses, there is no call to system free, so my double free theory is out the window:
Code:
[206-72-79-245:wizards/source/formwizard] peterlin% gdb /Volumes/abyss/neoj11/neojava/build/solver/645/unxmacxp.pro/bin/rscdep
GNU gdb 6.1-20040303 (Apple version gdb-384) (Mon Mar 21 00:05:26 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ........ done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004b441
0x01031abc in CBlock::Insert (this=0x160eed0, p=0x160eeb0, nIndex=60688, nReSize=16) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:266
266 pNodes[nIndex] = p;
(gdb) b dirent.cxx:2531
Breakpoint 1 at 0x105bb98: file /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx, line 2531.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Volumes/abyss/neoj11/neojava/build/solver/645/unxmacxp.pro/bin/rscdep -CHARSET_DONTKNOW -s -I. -I -I../inc -I../../inc -I../../unxmacxp.pro/inc -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DSOLAR_JAVA -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" -fp../../unxmacxp.pro/srs/dbwizres.srs dbwizres.src
nlsupport.c: _imp_getProcessLocale() returning en_US.UTF-8 as current locale.
Breakpoint 1, DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2531
2531 if ( ( aStack.Count() == 0 ) ||
(gdb) n
2534 aStack.Push( new DirEntry( ByteString(), FSYS_FLAG_PARENT, eStyle ) );
(gdb)
2562 aPfad.Erase( 0, nPos + 1 );
(gdb) b free
[0] cancel
[1] all
Breakpoint 1, DirEntry::ImpParseUnixName (this=0xbfffc410, rPfad=@0xbfffc050, eStyle=FSYS_STYLE_BSD) at /Volumes/abyss/neoj11/neojava/build/tools/source/fsys/dirent.cxx:2531
2531 if ( ( aStack.Count() == 0 ) ||
(gdb)
Continuing.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004b441
0x01031abc in CBlock::Insert (this=0x160eed0, p=0x160eeb0, nIndex=60688, nReSize=16) at /Volumes/abyss/neoj11/neojava/build/tools/source/memtools/contnr.cxx:266
266 pNodes[nIndex] = p;
Thoughts? I'm also debugging with a sal that has debug symbols. I still can't track down where operator new is.
Only thing that is now coming to mind is that perhaps the -lstdc++ that's on all of the link lines for building on tiger is pulling in "libstdc++.dylib" instead of the gcc3.3 static C++ runtime library perhaps?
All times are GMT - 7 Hours Goto page 1, 2, 3, 4, 5, 6, 7Next
Page 1 of 7
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
), so in theory it should be possible....
Most makefile based apps can't handle them properly. Heck, not even XCode handles them right!