llvm dev - Aug 2008 - [LLVMdev] gfortran link failure in current llvm svn

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.