On 2019/2/14 12:45, Olivier Houchard wrote:
> Hi Patrick,
>
> On Thu, Feb 14, 2019 at 09:12:18AM -0500, Patrick Hemmer wrote:
>>
>> On 2019/2/14 08:20, Frederic Lecaille wrote:
>>> On 2/14/19 1:32 PM, Frederic Lecaille wrote:
>>>> On 2/13/19 7:30 PM, Patrick Hemmer wrote:
>>>>>
>>>>> On 2019/2/13 10:29, Olivier Houchard wrote:
>>>>>> Hi Patrick,
>>>>>>
>>>>>> On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote:
>>>>>>> On 2019/2/13 09:40, Aleksandar Lazic wrote:
>>>>>>>> Am 13.02.2019 um 14:45 schrieb Patrick Hemmer:
>>>>>>>>> Trying to compile haproxy on my local machine for testing
>>>>>>>>> purposes and am
>>>>>>>>> running into the following:
>>>>>>>> Which compiler do you use?
>>>>>>>     # gcc -v
>>>>>>>     Configured with:
>>>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr
>>>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>>>>>>>     Apple LLVM version 9.0.0 (clang-900.0.39.2)
>>>>>>>     Target: x86_64-apple-darwin17.7.0
>>>>>>>     Thread model: posix
>>>>>>>     InstalledDir:
>>>>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>>>>>>>
>>>>>>>
>>>>>>>>>          # make TARGET=osx
>>>>>>>>>          src/proto_http.c:293:1: error: argument to 'section'
>>>>>>>>> attribute is not
>>>>>>>>> valid for this target: mach-o section specifier requires a
>>>>>>>>> segment and section
>>>>>>>>> separated by a comma
>>>>>>>>>          DECLARE_POOL(pool_head_http_txn, "http_txn",
>>>>>>>>> sizeof(struct http_txn));
>>>>>>>>>          ^
>>>>>>>>>          include/common/memory.h:128:2: note: expanded from
>>>>>>>>> macro 'DECLARE_POOL'
>>>>>>>>>                          REGISTER_POOL(&ptr, name, size)
>>>>>>>>>                          ^
>>>>>>>>>          include/common/memory.h:123:2: note: expanded from
>>>>>>>>> macro 'REGISTER_POOL'
>>>>>>>>>                          INITCALL3(STG_POOL,
>>>>>>>>> create_pool_callback, (ptr), (name),
>>>>>>>>> (size))
>>>>>>>>>                          ^
>>>>>>>>>          include/common/initcall.h:102:2: note: expanded from
>>>>>>>>> macro 'INITCALL3'
>>>>>>>>>                          _DECLARE_INITCALL(stage, __LINE__,
>>>>>>>>> function, arg1, arg2,
>>>>>>>>> arg3)
>>>>>>>>>                          ^
>>>>>>>>>          include/common/initcall.h:78:2: note: expanded from macro
>>>>>>>>> '_DECLARE_INITCALL'
>>>>>>>>>                          __DECLARE_INITCALL(__VA_ARGS__)
>>>>>>>>>                          ^
>>>>>>>>>          include/common/initcall.h:65:42: note: expanded from macro
>>>>>>>>> '__DECLARE_INITCALL'
>>>>>>>>> __attribute__((__used__,__section__("init_"#stg))) =   \
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Issue occurs on master, and the 1.9 branch
>>>>>>>>>
>>>>>>>>> -Patrick
>>>>>> Does the (totally untested, because I have no Mac to test) patch
>>>>>> works for
>>>>>> you ?
>>>>> Unfortunately not. Just introduces a lot of new errors:
>>>>>
>>>>>
>>>>>      In file included from src/ev_poll.c:22:
>>>>>      In file included from include/common/hathreads.h:26:
>>>>>      include/common/initcall.h:134:22: error: expected ')'
>>>>>      DECLARE_INIT_SECTION(STG_PREPARE);
>>>>>                                               ^
>>>>>      include/common/initcall.h:134:1: note: to match this '('
>>>>>      DECLARE_INIT_SECTION(STG_PREPARE);
>>>>>      ^
>>>>>      include/common/initcall.h:124:82: note: expanded from macro
>>>>> 'DECLARE_INIT_SECTION'
>>>>>                      extern __attribute__((__weak__)) const struct
>>>>> initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \
>>>>> ^
>>>> Try to use -E in place of -c option of your compiler to stop after
>>>> having preprocessed the code. Then have a look to how the code of
>>>> src/ev_poll.c was preprocessed.
>>>>
>>>> This should help.
>>>>
>>>> Fred.
>>> As this sounds to be a preprocessing issue, and to have a look to how
>>> the code is preprocessed for Apple we can invert the two #ifdef
>>> __APPLE__  condition of Olivier's patch to use the same preprocessor
>>> commands on a Linux system.
>>>
>>>
>>> Here is the code after having preprocessed it:
>>>
>>>
>>> # 134 "include/common/initcall.h"
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern
>>> __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK
>>> __asm("section$end$__DATA$" STG_LOCK);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_POOL __asm("section$start$__DATA$" STG_POOL); extern
>>> __attribute__((__weak__)) const struct initcall *__stop_init_STG_POOL
>>> __asm("section$end$__DATA$" STG_POOL);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_REGISTER __asm("section$start$__DATA$"
>>> STG_REGISTER); extern __attribute__((__weak__)) const struct initcall
>>> *__stop_init_STG_REGISTER __asm("section$end$__DATA$" STG_REGISTER);
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_INIT __asm("section$start$__DATA$" STG_INIT); extern
>>> __attribute__((__weak__)) const struct initcall *__stop_init_STG_INIT
>>> __asm("section$end$__DATA$" STG_INIT);
>>>
>>>
>>>
>>> should be I guess
>>>
>>> extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_STG_PREPARE __asm("section$start$__DATA$STG_PREPARE");
>>>
>>> etc.
>>>
>>>
>>> and the compiler warns like this:
>>>
>>>
>>> $ gcc -Iinclude -Iebtree -Wall -Wextra  -O2 -g -fno-strict-aliasing
>>> -Wdeclaration-after-statement -fwrapv   -Wno-unused-label
>>> -Wno-sign-compare -Wno-unused-parameter -Wno-old-style-declaration
>>> -Wno-ignored-qualifiers -Wno-clobbered -Wno-missing-field-initializers
>>>  -Wtype-limits -Wshift-negative-value -Wshift-overflow=2
>>> -Wduplicated-cond -Wnull-dereference       -DCONFIG_HAP_LINUX_SPLICE
>>> -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H
>>> -DUSE_ZLIB  -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY
>>> -DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_THREAD
>>> -DUSE_OPENSSL  -DUSE_SYSCALL_FUTEX -DUSE_LUA -I/opt/local/include
>>> -DUSE_PCRE -I/usr/include
>>> -DCONFIG_HAPROXY_VERSION=\"2.0-dev0-85ab28-296\"
>>> -DCONFIG_HAPROXY_DATE=\"2019/02/14\" -c -o src/ev_poll.o src/ev_poll.c
>>> In file included from include/common/hathreads.h:26:0,
>>>                  from src/ev_poll.c:22:
>>> include/common/initcall.h:134:22: error: expected ‘)’ before
>>> ‘STG_PREPARE’
>>>  DECLARE_INIT_SECTION(STG_PREPARE);
>>>                       ^
>>> include/common/initcall.h:124:107: note: in definition of macro
>>> ‘DECLARE_INIT_SECTION’
>>>   extern __attribute__((__weak__)) const struct initcall
>>> *__start_init_##stg __asm("section$start$__DATA$" stg); \
>>>
>>>                                    ^~~
>>> include/common/initcall.h:134:22: error: expected ‘)’ before
>>> ‘STG_PREPARE’
>>>  DECLARE_INIT_SECTION(STG_PREPARE);
>>>
>>> sounds similar to Patrick's issue.
>>>
>>>
>>>
>> Yes, that is the generated code I end up with.
>>
>> Just fumbling around, but if I change the macro to stringize the arg:
>>     extern __attribute__((__weak__)) const struct initcall
>> *__start_init_##stg __asm("section$start$__DATA$" #stg); \
>>     extern __attribute__((__weak__)) const struct initcall
>> *__stop_init_##stg __asm("section$end$__DATA$" #stg)
>>
>> I end up with:
>>     src/hlua.c:8301:1: error: argument to 'section' attribute is not
>> valid for this target: mach-o section
>>       specifier requires a section whose length is between 1 and 16
>> characters
>>
>> So now it seems like it's just too long.
>> But this is much lower level than I'm used to dealing with, so just a guess.
> Hi Patrick,
>
> So, I finally got my hand on a shell on an OS X machine.
> With the attached patch, it now builds for me, and it even seems to work !
> Please let me know if it fixes your issues.
>
> Regards,
>
> Olivier

Indeed, this fixes it for me.

Thanks!

-Patrick

Reply via email to