Peter,
Regarding your original question, I found something which may be a
workaround.
Looking at the darwin ld code, it doesn't throw if you use the
-flat_namespace arg. So you could add -Wl,-flat_namespace to your clang
args. This makes linking succeed for me.
That said, when I run the binary, I'm getting
dyld: Library not loaded: @rpath/libmathtest.1.dylib
Referenced from: /Users/andy/dev/zig/example/shared_library/zig-cache/test
Reason: image not found
But I suspect this may be a separate issue.
Regards,
Andrew
On Tue, May 16, 2017 at 4:39 PM, Andrew Kelley <superjoe30 at gmail.com>
wrote:
> Lang - I think there has perhaps been a regression in that case, because I
> have an example of a trivial IR module that fails to be linked correctly:
> https://bugs.llvm.org/show_bug.cgi?id=32376
>
> Kevin provided some clues about this but I was not able to find a fix.
>
> On Tue, May 16, 2017 at 12:24 PM, Lang Hames <lhames at gmail.com>
wrote:
>
>> Hi Guys,
>>
>> As I left it, lld on Darwin could compile Clang / LLVM and the nightly
>> test suite, so we were definitely making progress. There were still
plenty
>> of bug fixes to get through though. If anyone's interested in
contributing
>> to MachO support in lld I'm happy to translate some of the radars
into
>> llvm.org bugs.
>>
>> Cheers,
>> Lang.
>>
>>
>> On Thu, May 11, 2017 at 11:34 PM, Peter Kriens <peter.kriens at
aqute.biz>
>> wrote:
>>
>>> Sounds like a fantastic goal, and enticingly close …
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> On 11 May 2017, at 20:53, Andrew Kelley <superjoe30 at
gmail.com> wrote:
>>>
>>> Zig author here in the same boat. Looks like I'm going to have
to
>>> disable cross compiling for MacOS and when compiling native for
MacOS add a
>>> dependency on the system linker. Really looking forward to Mach-O
support
>>> in LLD, because at that point my users will be able to cross
compile for
>>> any OS out of the box.
>>>
>>> On Thu, May 11, 2017 at 1:37 PM, Peter Kriens via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Thanks for the answer. However, this means I need a different
linker
>>>> for MacOS as for Windows/Linux?
>>>>
>>>> I guess it is a not a major thing but I was hoping to set up a
cross
>>>> compile env. where only the header files and shared libraries
differed :-(
>>>> I guess we’re not there yet … :-)
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>> On 6 May 2017, at 19:57, Lang Hames <lhames at gmail.com>
wrote:
>>>>
>>>> LLD work on Darwin is stalled out at the moment. Patches are
welcome
>>>> (and I'll try to find time to review them), but I'd
recommend ld64 for any
>>>> real-world linking.
>>>>
>>>> - Lang.
>>>>
>>>>
>>>> On Thu, Apr 27, 2017 at 11:06 AM, Rui Ueyama <ruiu at
google.com> wrote:
>>>>
>>>>> Cc'ing people who are working on macOS.
>>>>>
>>>>> On Thu, Apr 27, 2017 at 9:05 AM, Peter Kriens via llvm-dev
<
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hopefully the right list … otherwise pointers
appreciated (I’ve spent
>>>>>> days trying to find a solution but could not find
sufficient documentation,
>>>>>> could not find a proper list of -flavor darwin
commands)
>>>>>>
>>>>>> I am setting up an environment for cross compiling
shared libraries
>>>>>> using LLVM. Overall this works perfectly for many unix
like environments
>>>>>> but MacOS is a pain in the ass despite that I am
running on MacOS. (I’ve
>>>>>> not tried windows yet.)
>>>>>>
>>>>>> I seem to be able to compile with clang a proper mach
object file for
>>>>>> a hello function. However, when I link this function
into a shared library
>>>>>> I (surprisingly for a shared lib?) get undefined
symbols like _printf, stub
>>>>>> runtime: dyld_stub_binder, _main, etc. Using the flag
>>>>>>
>>>>>> -undefined dynamic_lookup
>>>>>>
>>>>>> I get no errors or warnings but then when I try to link
the shared
>>>>>> library to a main program I get the error:
>>>>>>
>>>>>> ld: malformed dylib has MH_NO_REEXPORTED_DYLIBS flag
>>>>>> but no LC_REEXPORT_DYLIB load commands:
./libhello.dylib file
>>>>>> './libhello.dylib'
>>>>>>
>>>>>> I’ve included the shell file that makes the hello
shared lib and the
>>>>>> command that I use to link the file.
>>>>>>
>>>>>> Thanks for any help, this looks like an amazing
solution if it can
>>>>>> get to work on all supported platforms.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Peter Kriens
>>>>>>
>>>>>> $ /usr/local/Cellar/llvm/4.0.0_1/bin/clang \
>>>>>> -target x86_64-apple-darwin16.5.0 \
>>>>>> -Ienvs/x86_64/apple/macos/darwin/16.5.0/include \
>>>>>> -v \
>>>>>> -nostdinc \
>>>>>> -fPIC \
>>>>>> -c \
>>>>>> -Wno-nullability-completeness \
>>>>>> hello.c x.c
>>>>>>
>>>>>> $ file hello.o
>>>>>> hello.o: Mach-O 64-bit object x86_64
>>>>>>
>>>>>> $ /usr/local/Cellar/llvm/4.0.0_1/bin/ld.lld \
>>>>>> -flavor darwin \
>>>>>> -v \
>>>>>> -sdk_version 10.5.0 \
>>>>>> -demangle \
>>>>>> -arch x86_64 \
>>>>>> -undefined dynamic_lookup \
>>>>>> -dylib \
>>>>>> -dynamic \
>>>>>> -o libhello.dylib \
>>>>>> hello.o
>>>>>>
>>>>>> $ file libhello.dylib
>>>>>> libhello.dylib: Mach-O 64-bit dynamically linked shared
library x86_64
>>>>>>
>>>>>> $ gcc x.c -L. -lhello
>>>>>> ld: malformed dylib has MH_NO_REEXPORTED_DYLIBS flag
but no
>>>>>> LC_REEXPORT_DYLIB load commands: ./libhello.dylib file
‘./libhello.dylib'
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170827/ac5fbd05/attachment.html>