On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote:> Hi Jack, > >> The curent llvm svn (r54623) is unable to link the gfortran >> compiler in llvm-gcc-4.2 svn. I am getting the error... > ... >> Undefined symbols: >> "_create_init_utf16_var", referenced from: >> _darwin_build_constant_cfstring in libbackend.a(darwin.o) > > this is probably due to recent Apple changes. Fortran builds on > linux. > >>I just looked at what's going on here, and I threw up a little in my mouth. It's just horrendous. For some reason, they placed a whole bunch of ObjC-building code into darwin.c, then had it call this function in darwin-c.c. If I try to put that function into darwin.c, all hell breaks loose. So even though the Fortran stuff wouldn't call the Obj-C stuff in darwin.c, it appears like it still needs the darwin-c.c file linked in with it. -bw
IMHO, this is one of my biggest concerns about Apple eventually
switching over to llvm-gcc. The absence of the rigorous patch
review process required in FSF gcc will tend to allow these sort
of issues to slip by.
Jack
On Tue, Aug 12, 2008 at 09:05:11PM -0700, Bill Wendling
wrote:> On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote:
>
>> Hi Jack,
>>
>>> The curent llvm svn (r54623) is unable to link the gfortran
>>> compiler in llvm-gcc-4.2 svn. I am getting the error...
>> ...
>>> Undefined symbols:
>>> "_create_init_utf16_var", referenced from:
>>> _darwin_build_constant_cfstring in libbackend.a(darwin.o)
>>
>> this is probably due to recent Apple changes. Fortran builds on
>> linux.
>>
>>>
> I just looked at what's going on here, and I threw up a little in my
> mouth.
>
> It's just horrendous. For some reason, they placed a whole bunch of
> ObjC-building code into darwin.c, then had it call this function in
> darwin-c.c. If I try to put that function into darwin.c, all hell breaks
> loose. So even though the Fortran stuff wouldn't call the Obj-C stuff
in
> darwin.c, it appears like it still needs the darwin-c.c file linked in
> with it.
>
> -bw
It's not an llvm-gcc vs gcc thing. We sync our code base up with Apple's gcc branch. -bw On Aug 12, 2008, at 9:13 PM, Jack Howarth wrote:> IMHO, this is one of my biggest concerns about Apple eventually > switching over to llvm-gcc. The absence of the rigorous patch > review process required in FSF gcc will tend to allow these sort > of issues to slip by. > Jack > > On Tue, Aug 12, 2008 at 09:05:11PM -0700, Bill Wendling wrote: >> On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote: >> >>> Hi Jack, >>> >>>> The curent llvm svn (r54623) is unable to link the gfortran >>>> compiler in llvm-gcc-4.2 svn. I am getting the error... >>> ... >>>> Undefined symbols: >>>> "_create_init_utf16_var", referenced from: >>>> _darwin_build_constant_cfstring in libbackend.a(darwin.o) >>> >>> this is probably due to recent Apple changes. Fortran builds on >>> linux. >>> >>>> >> I just looked at what's going on here, and I threw up a little in my >> mouth. >> >> It's just horrendous. For some reason, they placed a whole bunch of >> ObjC-building code into darwin.c, then had it call this function in >> darwin-c.c. If I try to put that function into darwin.c, all hell >> breaks >> loose. So even though the Fortran stuff wouldn't call the Obj-C >> stuff in >> darwin.c, it appears like it still needs the darwin-c.c file linked >> in >> with it. >> >> -bw
On Aug 12, 2008, at 9:05 PM, Bill Wendling wrote:> It's just horrendous.The standard answer, we welcome your contribution.> it appears like it still needs the darwin-c.c file linked in with it.No. That way lies insanity. You want to create stub routines in the ada/java/fortran front ends, or move the C specific bits into darwin- c.c and ensure that the language independent parts don't directly call anything from a C part.
> > it appears like it still needs the darwin-c.c file linked in with it. > > No. That way lies insanity. You want to create stub routines in the > ada/java/fortran front ends, or move the C specific bits into darwin- > c.c and ensure that the language independent parts don't directly call > anything from a C part.There are already stub-c.c and stub-objc.c, which are used by the various non-C front-ends to work around the existing worms in the Apple. Ciao, Duncan.
On Aug 12, 2008, at 9:05 PM, Bill Wendling wrote:> For some reason, they placed a whole bunch of > ObjC-building code into darwin.c, then had it call this function in > darwin-c.c. If I try to put that function into darwin.c, all hell > breaks loose. So even though the Fortran stuff wouldn't call the Obj-C > stuff in darwin.c, it appears like it still needs the darwin-c.c file > linked in with it.You add these routines in stub-objc.c for other FEs. - Devang
On Aug 13, 2008, at 10:11 AM, Devang Patel wrote:> On Aug 12, 2008, at 9:05 PM, Bill Wendling wrote: >> For some reason, they placed a whole bunch of >> ObjC-building code into darwin.c, then had it call this function in >> darwin-c.c. If I try to put that function into darwin.c, all hell >> breaks loose. So even though the Fortran stuff wouldn't call the >> Obj-C >> stuff in darwin.c, it appears like it still needs the darwin-c.c file >> linked in with it. > > You add these routines in stub-objc.c for other FEs.This is wrong in this case.
On Aug 13, 2008, at 9:06 AM, Mike Stump wrote:> On Aug 12, 2008, at 9:05 PM, Bill Wendling wrote: >> It's just horrendous. > > The standard answer, we welcome your contribution. >Actually, the standard answer is that it should have been architected correctly in the first place... -bw
> I just looked at what's going on here, and I threw up a little in my > mouth.Just for the record, I agree totally with Bill here. One of the most off-putting things when I started working on the llvm-gcc Ada front-end was seeing the poor quality of some of the Apple changes. I'm mostly thinking of generic code that was modified to call back into the C-like front-ends, like this latest example. I can understand that Apple is only interested in C-like languages, and that it was easier to change things as they did rather than put in the extra time and effort required to design a language-independent solution. It also wasn't hard to "fix" these problems: I introduced stub-c.c and stub-objc.c for that. But it did leave a bad taste in my mouth, and is one of the reasons I would like to rebase llvm-gcc on top of mainline gcc, and have Apple make their changes on top of llvm-gcc in their own branch, rather than the other way round. That way Apple can concentrate on the languages they care about, while llvm-gcc can remain language agnostic. Best wishes, Duncan.