variable table in backend
Hi, Is there a structure/array/macro to access all the variables (something like a variable table) in the back-end after the instantiation of the virtual registers (vregs pass from function.c) ? Some info about variable + its virtual register and so on. Thanks, Thomas
Re: gcc source: how can access asmspec_tree in function push_parm_decl
Hello Ian
On 03.10.08, you wrote:
>> but the func
>>
>> push_parm_decl
>>
>> have no parameter asmspec_tree.
>
> It shouldn't need one.
>
> I'm not sure what the semantics of this should be. Are you trying to
> change the calling convention for a function? Should it change what
> callers of the function do?
amigaos need Explicit register specification.see below the docu.
it seem other targets need this feature not, i dont know how this on other
OS work when they have a register ABI to OS functions.
Dont understand me wrong, i dont want that this feature is in gcc(i think if
it is not in, other developers need it not), i only want ask, if there is
on newest gcc a more easy way to add this feature, so i must not merge so
much in gcc files in.
i can build a workable gcc4.4.0 for amigaos but of course not usefull
because this feature is often need.
And here is what docu say to the amigaos extension.
[EMAIL PROTECTED] Explicit register specification, Case sensitive CPP,
Miscellaneous,
Miscellaneous
+In certain situations, like writing callback hooks, ``patchers'',
+standard shared libraries, etc., functions have to receive arguments
+in particular registers.
+To overcome this problem in the AmigaOS port of @samp{GCC}, explicit
+register specification has been extended to be available for function
+arguments, as well:
+
[EMAIL PROTECTED]
+void myhook(struct Hook* hook __asm("a0"), APTR object __asm("a2"),
+APTR message __asm("a1"))
[EMAIL PROTECTED]
+ ...
[EMAIL PROTECTED]
[EMAIL PROTECTED] example
+
[EMAIL PROTECTED]
[EMAIL PROTECTED]: This feature is currently not available in @samp{G++}.
+
+Only the @samp{ANSI}-style declarations (prototypes) are supported.
+
+Registers have to be specified both in function declarations
+(prototypes) and definitions (function code).
[EMAIL PROTECTED] quotation
+
+This feature was first made available in the @samp{GCC} 2.7.2.1,
[EMAIL PROTECTED] Gadgets} snapshot @samp{961012}.
on old amigaos code, i get gcc workung with that header file and replace
some gcc functions.here i can code in seperate file.
Note:
below code contain much more than really need, amiga os target have regparm
option, to transfer arguments not in stack.but this is only a theoretical
speed feature i dont need, becaue inline func and optimizer work good on
GCC above gcc2.9
Only the feature Explicit register specification i like to add if it is
possible.
maybe this feature can too code in seperate file ?
here is in short what gcc functions are remap to a seperate file called
amigaos.c
#undef INIT_CUMULATIVE_ARGS
#define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT, N_NAMED_ARGS) \
(amigaos_init_cumulative_args(&(CUM), (FNTYPE)))
/* Update the data in CUM to advance over an argument
of mode MODE and data type TYPE.
(TYPE is null for libcalls where that information may not be available.)
*/
#undef FUNCTION_ARG_ADVANCE
#define FUNCTION_ARG_ADVANCE(CUM, MODE, TYPE, NAMED)\
(amigaos_function_arg_advance (&(CUM)))
/* A C expression that controls whether a function argument is passed
in a register, and which register. */
#undef FUNCTION_ARG
#define FUNCTION_ARG(CUM, MODE, TYPE, NAMED) \
(amigaos_function_arg (&(CUM), (MODE), (TYPE)))
#endif //REGPARMS_68K
/* end-GG-local */
/* Stack checking and automatic extension support. */
#define PROLOGUE_BEGIN_HOOK(STREAM, FSIZE) \
(amigaos_prologue_begin_hook ((STREAM), (FSIZE)))
#define HAVE_ALTERNATE_FRAME_SETUP_F(FSIZE) TARGET_STACKEXTEND
#define ALTERNATE_FRAME_SETUP_F(STREAM, FSIZE) \
(amigaos_alternate_frame_setup_f ((STREAM), (FSIZE)))
#define HAVE_ALTERNATE_FRAME_SETUP(FSIZE) TARGET_STACKEXTEND
#define ALTERNATE_FRAME_SETUP(STREAM, FSIZE)\
(amigaos_alternate_frame_setup ((STREAM), (FSIZE)))
#define HAVE_ALTERNATE_FRAME_DESTR_F(FSIZE) \
(TARGET_STACKEXTEND && current_function_calls_alloca)
#define ALTERNATE_FRAME_DESTR_F(STREAM, FSIZE) \
(asm_fprintf ((STREAM), "\tjra %U__unlk_a5_rts\n"))
#define HAVE_ALTERNATE_RETURN \
(TARGET_STACKEXTEND && frame_pointer_needed &&\
current_function_calls_alloca)
#define ALTERNATE_RETURN(STREAM)
#define HAVE_restore_stack_nonlocal TARGET_STACKEXTEND
#define gen_restore_stack_nonlocal gen_stack_cleanup_call
#define HAVE_restore_stack_function TARGET_STACKEXTEND
#define gen_restore_stack_function gen_stack_cleanup_call
#define HAVE_restore_stack_block TARGET_STACKEXTEND
#define gen_restore_stack_block gen_stack_cleanup_call
#undef TARGET_ALTERNATE_ALLOCATE_STACK
#define TARGET_ALTERNATE_ALLOCATE_STACK 1
#define ALTERNATE_ALLOCATE_STACK(OPERANDS) \
do \
{ \
amigaos_alternate_allocate_stack (OPERANDS);\
DONE; \
} \
while (0)
/* begin-GG-local: dynamic lib
Re: Extending a backend
I basically need to test the retarget ability of named address spaces, and it was determined that the best way to do this was to attempt to have the SPU implementation spit out a few assembly mnemonics that resemble what our architecture uses to handle multiple address spaces(hence the loads and stores). Then I have to see if I can make it generate errors when mutually exclusive address spaces are used interchangeably. Changing binutils would be the next step, however this is more of a proof of concept so my manager and I can see if gcc can be presented as an alternative compiler for our core. > The machine description is responsible for generating the assembly text > (you'll see plenty of obvious examples of this). Once the compiler is > emitting the right assembly source (compile with -S and inspect), then > you need to move onto the binutils to make the assembler recognise these > mnemonics. > Thanks, I have been using -S and reading examples/documentation on how to make RTLs. The SPU port is large and it gets a little tedious trying to experiment with RTL within it. I am trying to find a smaller template port to practice changing machine descriptions until I understand the necessary changes. Thanks for the help =^D, Gobi.
Re: IA64 HP-UX bug with C++ inline change (r138150)
I noticed that in start_cleanup_fn the statements: DECL_INLINE (fndecl) = 1; DECL_DECLARED_INLINE_P (fndecl) = 1; were removed. DECL_INLINE no longer exists but DECL_DECLARED_INLINE_P still exists and if I put that one back into start_cleanup_fn (in cp/decl.c) my small test case stops outputing _tcf_0 and things seem to work better. I will do a full bootstrap on this change and if that looks good submit a patch to gcc-patches. Steve Ellcey [EMAIL PROTECTED]
RFC: function parm attribute: must_assign
After upgrading to gcc-4.2.1 from a 3.4 version, I see that gcc now
complains about uninitialized variables even when their address is
passed to another function. Now that we get a warning about that
variable being possibly initialized, I'm forced to add an instruction
or two to initialize it (after I determine an appropriate value) or
declare the function like this:
foo( __attribute__((must_assign)) long *ptr);
{
*ptr = _base_address_;
}
bar()
{
int *p;
foo( &p);
*p = ...
}
There's two things I really like about this:
1) In the caller, my warning goes away without having to determine an
appropriate value in each caller of foo
2) In the callee, gcc can give a warning if there are any paths which
leave that parm uninitialized.
If there's some other mechanism to achieve this functionality, I'd be
interested in hearing about it. And if this is a new idea, I offer it
to the gcc community.
John
Re: real.h: REAL_VALUE_TO_TARGET_DOUBLE
On Thu, Oct 2, 2008 at 11:59 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Omar Torres" <[EMAIL PROTECTED]> writes: > >> Shouldn't this macro: >> #define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \ >> real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0)) >> >> be using DOUBLE_TYPE_SIZE instead of the hard coded '64'? Am I missing >> something here? > > That would certainly be more logical. In order to make that change, > you would have to consider each use of the macro to confirm that the > change would be valid. > > >> In the target I am currently working, DOUBLE_TYPE_SIZE is defined as >> 32-bit, so the hard-coded '64' is causing trouble. I am planning on >> doing this change on my local source tree, but wanted to discuss with >> the community to see if there is some implementations details somewhere >> that I need to consider as well. > > As far as I can see, all but one use of this macro is in target > dependent code. Are you having trouble from the single target > independent use? Or perhaps your target dependent code should just > use REAL_VALUE_TO_TARGET_SINGLE instead? > > Ian > Both. Yes, I can use REAL_VALUE_TO_TARGET_SINGLE in the target dependent files to work around this. I do not see a similar solution for the target independent code, since the size mismatch cause the incorrect format (encode/decode functions) to be use. Thanks, -Omar
Re: real.h: REAL_VALUE_TO_TARGET_DOUBLE
Omar Torres wrote: On Thu, Oct 2, 2008 at 11:59 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Omar Torres" <[EMAIL PROTECTED]> writes: Shouldn't this macro: #define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \ real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0)) be using DOUBLE_TYPE_SIZE instead of the hard coded '64'? Am I missing something here? That would certainly be more logical. In order to make that change, you would have to consider each use of the macro to confirm that the change would be valid. In the target I am currently working, DOUBLE_TYPE_SIZE is defined as 32-bit, so the hard-coded '64' is causing trouble. I am planning on doing this change on my local source tree, but wanted to discuss with the community to see if there is some implementations details somewhere that I need to consider as well. As far as I can see, all but one use of this macro is in target dependent code. Are you having trouble from the single target independent use? Or perhaps your target dependent code should just use REAL_VALUE_TO_TARGET_SINGLE instead? Ian Both. Yes, I can use REAL_VALUE_TO_TARGET_SINGLE in the target dependent files to work around this. I do not see a similar solution for the target independent code, since the size mismatch cause the incorrect format (encode/decode functions) to be use. The size of the C type "double" is controlled by DOUBLE_TYPE_SIZE, not the size of the compiler mode "DFmode". This macro is referring to the latter -- a double-precision floating point mode. r~
Re: real.h: REAL_VALUE_TO_TARGET_DOUBLE
On Fri, Oct 3, 2008 at 1:49 PM, Richard Henderson <[EMAIL PROTECTED]> wrote: > The size of the C type "double" is controlled by DOUBLE_TYPE_SIZE, > not the size of the compiler mode "DFmode". This macro is referring > to the latter -- a double-precision floating point mode. > > > r~ > Richard, I do not fully understand your comments, but I will like to. So your pacience is greatly appreciated. Here are some more specific's about the target I am working with: float maps to 3 byte (TQF) and and double maps to 4 byte (SF). This is how my target/target-modes.def file looks like: FLOAT_MODE (TQF, 3, cool_float_format); RESET_FLOAT_FORMAT (SF, cool_float_format); Now, given this information, looks like the macro in question (REAL_VALUE_TO_TARGET_DOUBLE) is implicitly forcing a 64-bit (DF) encoding into my target, which do not really exists. I understand my target is an outliner, but shouldn't the DOUBLE_TYPE_SIZE be used in this macro to cover targets like mine? Thanks, -Omar
GCC FTP mirror
Hi! I am inetested to setup a FTP mirror for the GCC distribution in Germany. How much disk space/bandwith does it need to provide a mirror? is it also possible to mirror through rsync? Thanks and best regards. Thomas Lepping
Re: RFC: function parm attribute: must_assign
[EMAIL PROTECTED] writes: > After upgrading to gcc-4.2.1 from a 3.4 version, I see that gcc now > complains about uninitialized variables even when their address is > passed to another function. This should only happen when gcc can see the called function and see that the value was used there before it was initialized. If you have a test case in which gcc warns inappropriately, that sounds like a bug. See http://gcc.gnu.org/bugs.html for bug reporting instructions. Ian
gcc-4.4-20081003 is now available
Snapshot gcc-4.4-20081003 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081003/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 140862 You'll find: gcc-4.4-20081003.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081003.tar.bz2 C front end and core compiler gcc-ada-4.4-20081003.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081003.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081003.tar.bz2 C++ front end and runtime gcc-java-4.4-20081003.tar.bz2 Java front end and runtime gcc-objc-4.4-20081003.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081003.tar.bz2The GCC testsuite Diffs from 4.4-20080926 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: libstdc++, gdb and darwin
On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote: > Jack Howarth wrote: > > Does anyone know why gdb appears to be unable to find the debug > > information > > for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported > > before > > as... > > > > https://trac.macports.org/ticket/16102 > > > > Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the > > errors of the form... > > > > warning: Could not find object file > > "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o" > > - no debug information available for > > "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c". > > > > when I try to run a binary linked to libstdc++ in gdb. My gcc build > > directory doesn't > > have a libstdc++.lax directory left in it. Is this a flaw in the .la files > > for gcc? > > Thanks in advance for any advice. I am trying to puzzle out if this is a > > gcc bug or > > a gdb bug so that I can file a radar report against gdb if it is the later. > > Jack > > > > The debug information is stored in the object files. Libtool uses a > convenience library, and, because darwin's linked does not have the > equivalent of --whole-archive --no-whole-archive to ensure that all > members of specific archives are loaded, it unpacks the archive and adds > all the objects. Having created the output, it then deletes these > objects, leaving the debugger with no object files. > > This is "fixed" in recent GNU libtool by calling dsymutil on the newly > created shared library. I have not checked if gcc's version of libtool > has this change. I'll check when I have time and submit a patch if that > is not the case. > > Peter > -- > Peter O'Gorman > http://pogma.com Peter, I am still seeing this problem with the current gcc trunk after the libtool update. Are we still messing some additional changes for darwin to eliminate these problems with Apple's gdb not properly finding the object files for libstdc++? Jack
Re: libstdc++, gdb and darwin
Jack Howarth wrote: > On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote: >> Jack Howarth wrote: >>> Does anyone know why gdb appears to be unable to find the debug >>> information >>> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported >>> before >>> as... >>> >>> https://trac.macports.org/ticket/16102 >>> >>> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the >>> errors of the form... >>> >>> warning: Could not find object file >>> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o" >>> - no debug information available for >>> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c". >>> >>> when I try to run a binary linked to libstdc++ in gdb. My gcc build >>> directory doesn't >>> have a libstdc++.lax directory left in it. Is this a flaw in the .la files >>> for gcc? >>> Thanks in advance for any advice. I am trying to puzzle out if this is a >>> gcc bug or >>> a gdb bug so that I can file a radar report against gdb if it is the later. >>> Jack >>> >> The debug information is stored in the object files. Libtool uses a >> convenience library, and, because darwin's linked does not have the >> equivalent of --whole-archive --no-whole-archive to ensure that all >> members of specific archives are loaded, it unpacks the archive and adds >> all the objects. Having created the output, it then deletes these >> objects, leaving the debugger with no object files. >> >> This is "fixed" in recent GNU libtool by calling dsymutil on the newly >> created shared library. I have not checked if gcc's version of libtool >> has this change. I'll check when I have time and submit a patch if that >> is not the case. > Peter, >I am still seeing this problem with the current gcc trunk after the > libtool update. Are we still messing some additional changes for darwin > to eliminate these problems with Apple's gdb not properly finding the > object files for libstdc++? > Jack Hi Jack, How are you starting GDB? Is your build tree still around with all the object files in it? Peter -- Peter O'Gorman http://pogma.com
Re: libstdc++, gdb and darwin
On Fri, Oct 03, 2008 at 08:29:40PM -0500, Peter O'Gorman wrote:
> Jack Howarth wrote:
> > On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote:
> >> Jack Howarth wrote:
> >>> Does anyone know why gdb appears to be unable to find the debug
> >>> information
> >>> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported
> >>> before
> >>> as...
> >>>
> >>> https://trac.macports.org/ticket/16102
> >>>
> >>> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the
> >>> errors of the form...
> >>>
> >>> warning: Could not find object file
> >>> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
> >>> - no debug information available for
> >>> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c".
> >>>
> >>> when I try to run a binary linked to libstdc++ in gdb. My gcc build
> >>> directory doesn't
> >>> have a libstdc++.lax directory left in it. Is this a flaw in the .la
> >>> files for gcc?
> >>> Thanks in advance for any advice. I am trying to puzzle out if this is a
> >>> gcc bug or
> >>> a gdb bug so that I can file a radar report against gdb if it is the
> >>> later.
> >>> Jack
> >>>
> >> The debug information is stored in the object files. Libtool uses a
> >> convenience library, and, because darwin's linked does not have the
> >> equivalent of --whole-archive --no-whole-archive to ensure that all
> >> members of specific archives are loaded, it unpacks the archive and adds
> >> all the objects. Having created the output, it then deletes these
> >> objects, leaving the debugger with no object files.
> >>
> >> This is "fixed" in recent GNU libtool by calling dsymutil on the newly
> >> created shared library. I have not checked if gcc's version of libtool
> >> has this change. I'll check when I have time and submit a patch if that
> >> is not the case.
>
>
> > Peter,
> >I am still seeing this problem with the current gcc trunk after the
> > libtool update. Are we still messing some additional changes for darwin
> > to eliminate these problems with Apple's gdb not properly finding the
> > object files for libstdc++?
> > Jack
>
> Hi Jack,
>
> How are you starting GDB? Is your build tree still around with all the
> object files in it?
>
> Peter
> --
> Peter O'Gorman
> http://pogma.com
Peter,
If I compile a short c++ program like...
#include
using namespace std;
main()
{
cout << "Hello World!" << endl; cout << "Welcome to C++ Programming" <<
endl; }
with the g++ compiler from gcc trunk and execute...
gdb a.out
...using the Xcode 3.1.1 gdb under MacOS X 10.5.5 on Macintel, I get...
warning: Could not find object file
"/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
- no debug information available for
"../../../../gcc-4.4-20081001/libstdc++-v3/libmath/signbit.c".
..etc. The build directory from my fink packaging is still remaining but I
get...
ls -l
/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o
ls:
/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o:
No such file or directory
The
/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/
directory exists but it
doesn't contain a libstdc++.lax subdirectory.
Jack
Re: libstdc++, gdb and darwin
Jack Howarth wrote:
> On Fri, Oct 03, 2008 at 08:29:40PM -0500, Peter O'Gorman wrote:
>> Jack Howarth wrote:
>>> On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote:
Jack Howarth wrote:
> Does anyone know why gdb appears to be unable to find the debug
> information
> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported
> before
> as...
>
> https://trac.macports.org/ticket/16102
>
> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the
> errors of the form...
>
> warning: Could not find object file
> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
> - no debug information available for
> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c".
>
> when I try to run a binary linked to libstdc++ in gdb. My gcc build
> directory doesn't
> have a libstdc++.lax directory left in it. Is this a flaw in the .la
> files for gcc?
> Thanks in advance for any advice. I am trying to puzzle out if this is a
> gcc bug or
> a gdb bug so that I can file a radar report against gdb if it is the
> later.
> Jack
>
The debug information is stored in the object files. Libtool uses a
convenience library, and, because darwin's linked does not have the
equivalent of --whole-archive --no-whole-archive to ensure that all
members of specific archives are loaded, it unpacks the archive and adds
all the objects. Having created the output, it then deletes these
objects, leaving the debugger with no object files.
This is "fixed" in recent GNU libtool by calling dsymutil on the newly
created shared library. I have not checked if gcc's version of libtool
has this change. I'll check when I have time and submit a patch if that
is not the case.
>>
>>> Peter,
>>>I am still seeing this problem with the current gcc trunk after the
>>> libtool update. Are we still messing some additional changes for darwin
>>> to eliminate these problems with Apple's gdb not properly finding the
>>> object files for libstdc++?
>>> Jack
>> Hi Jack,
>>
>> How are you starting GDB? Is your build tree still around with all the
>> object files in it?
>>
>> Peter
>> --
>> Peter O'Gorman
>> http://pogma.com
>
> Peter,
>If I compile a short c++ program like...
>
> #include
> using namespace std;
> main()
> {
> cout << "Hello World!" << endl; cout << "Welcome to C++ Programming" <<
> endl; }
>
> with the g++ compiler from gcc trunk and execute...
>
> gdb a.out
>
> ...using the Xcode 3.1.1 gdb under MacOS X 10.5.5 on Macintel, I get...
>
> warning: Could not find object file
> "/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
> - no debug information available for
> "../../../../gcc-4.4-20081001/libstdc++-v3/libmath/signbit.c".
>
> ..etc. The build directory from my fink packaging is still remaining but I
> get...
>
> ls -l
> /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o
> ls:
> /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o:
> No such file or directory
>
> The
> /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/
> directory exists but it
> doesn't contain a libstdc++.lax subdirectory.
> Jack
Jack,
Some libraries are created from GNU libtool convenience archives, on
darwin. Those used to be included in the archive with the -all_load flag
to the static linker, but this was not ideal, as the -all_load flag adds
every member of every archive to the output. So this was changed to the
current system where archives that need all members to be added to the
output are extracted (fat archives are dealt with with lipo), and all
the individual objects are then added to the output. Because these
convenience archives can, for some projects, involve thousands of object
files, once the output is created, GNU libtool deletes the object files
that it created in that temporary directory.
Because, on Mac OS X, DWARF-2 debugging information is stored in the
object file, I received reports (from Apple engineers) that it was
difficult to debug libraries in this case (the object files had been
removed, so GDB was unable to find the debug information). I added the
dsymutil step to library linking to allow developers to debug their
shared libraries in the build tree. This works as long as the library
that gdb finds is the one in the build tree that has the .dSYM directory
sitting next to it. If a library containing debug information, but no
corresponding object files or .dSYM directory is found by
