discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test on Ubuntu 12.04 64bits


From: Benoît Garrigues
Subject: Re: Test on Ubuntu 12.04 64bits
Date: Sat, 26 May 2012 21:12:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Another try with the following change in Source/GNUmakefile (edited by
hand) :

#libgnustep-corebase_LIBRARIES_DEPEND_UPON += -licui18n -licuuc -licudata
libgnustep-corebase_LIBRARIES_DEPEND_UPON += -licui18n -licuuc -licudata
-l:libobjc.so.4

To correct this problem, it is probably possible to use the
"gnustep-config" tool with the "--objc-libs" flag.


So now the libobjc is the same (checked with ldd) in
libgnustep-base.so.1.24 and the tests tools.
The error and stack trace in gdb is always the same.

There is an incompatibility between corebase and the gnustep runtime. I
tested also with the svn version of libobjc2 without success.


Benoit

Le 26/05/2012 20:15, Stefan Bidi a écrit :
> A lot of this likely has to do with how corebase is configured, than.
> The configure script searches for libobjc and settles on the first one
> it finds.  The disable-objc-bridge option doesn't completely do away
> with the objc stuff, it gets simply disables the ability to call CF
> functions on objc objects.  Some of the configure options are still
> not 100% (icu, for example cannot be disabled and I'm going to remove
> the configure option before the release).
>
> Another problem can be due to the fact that -corebase does way too
> much work with the objc runtime at load time.  Some of that is kind of
> fragile.  The point at which it is crashing is when +[NSCFType class]
> is called, and this call is done at load time.  That said, the call is
> complete unneeded and shouldn't be here since the variable that uses
> the result is already set somewhere else.  I'd still like to know why
> the call is crashing, though.
>
> On Sat, May 26, 2012 at 12:33 PM, Benoît Garrigues <bgarrigues@gmail.com> 
> wrote:
>> When configuring corebase with --disable-objc-bridge :
>>
>> $ make check
>> ...
>>
>>     27 Failed files
>>      8 Failed builds
>>
>>
>> $ ldd Source/obj/libgnustep-corebase.so
>>        linux-vdso.so.1 =>  (0x00007fff54dff000)
>>        libicui18n.so.48 => /usr/lib/libicui18n.so.48 (0x00007f094c5f8000)
>>        libicuuc.so.48 => /usr/lib/libicuuc.so.48 (0x00007f094c28e000)
>>        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>> (0x00007f094c070000)
>>        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f094bcb3000)
>>        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> (0x00007f094b9b3000)
>>        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f094b6b8000)
>>        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>> (0x00007f094b4a2000)
>>        libicudata.so.48 => /usr/lib/libicudata.so.48 (0x00007f094a132000)
>>        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0949f2d000)
>>        /lib64/ld-linux-x86-64.so.2 (0x00007f094cc3b000)
>>
>> => no dependency to libobjc : ok
>>
>>
>> $ ldd Tests/CFArray/obj/create
>>        linux-vdso.so.1 =>  (0x00007fff208fe000)
>>        libgnustep-base.so.1.24 =>
>> /usr/GNUstep/Local/Library/Libraries/libgnustep-base.so.1.24
>> (0x00007f9dccc5f000)
>>        libgnustep-corebase.so.0 => not found
>>        /usr/local/lib/libobjc.so.4 (0x00007f9dcca11000)
>>        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>> (0x00007f9dcc7f4000)
>>        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9dcc437000)
>>        ...
>>
>> => the test tool is linked with libobjc and gnustep-base
>>
>>
>> gdb ./Tests/CFArray/obj/create
>> (gdb) run
>> Starting program:
>> /home/benoit/Projets/OpenSource/objc/GNUstep-anonymous/dev-libs/corebase/Tests/CFArray/obj/create
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7ffff2585700 (LWP 10459)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff7090687 in objc_msg_lookup_sender () from
>> /usr/local/lib/libobjc.so.4
>> (gdb) bt
>> #0  0x00007ffff7090687 in objc_msg_lookup_sender () from
>> /usr/local/lib/libobjc.so.4
>> #1  0x00007ffff7931142 in GSPrivateBuildStrings () at
>> /home/benoit/src/gnustep-base-1.24.0/Source/externs.m:239
>> #2  0x00007ffff7869cc3 in +[NSObject initialize] (self=<optimized out>,
>> _cmd=<optimized out>) at
>> /home/benoit/src/gnustep-base-1.24.0/Source/NSObject.m:1142
>> #3  0x00007ffff70874c4 in objc_send_initialize () from
>> /usr/local/lib/libobjc.so.4
>> #4  0x00007ffff70872b1 in objc_send_initialize () from
>> /usr/local/lib/libobjc.so.4
>> #5  0x00007ffff7090792 in objc_msg_lookup_sender () from
>> /usr/local/lib/libobjc.so.4
>> #6  0x00007ffff72d1ba7 in NSCFInitialize () at NSCFType.m:51
>> #7  0x00007ffff70853c6 in objc_send_load_message () from
>> /usr/local/lib/libobjc.so.4
>> #8  0x00007ffff7085ee7 in objc_resolve_class () from
>> /usr/local/lib/libobjc.so.4
>> #9  0x00007ffff7085fc3 in objc_resolve_class_links () from
>> /usr/local/lib/libobjc.so.4
>> #10 0x00007ffff7089e97 in __objc_exec_class () from
>> /usr/local/lib/libobjc.so.4
>> #11 0x00007ffff7de9306 in call_init (l=<optimized out>, argc=1,
>> argv=0x7fffffffdc78, env=0x7fffffffdc88) at dl-init.c:85
>> #12 0x00007ffff7de93df in call_init (env=<optimized out>,
>> argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at
>> dl-init.c:52
>> #13 _dl_init (main_map=0x7ffff7ffe2c8, argc=1, argv=0x7fffffffdc78,
>> env=0x7fffffffdc88) at dl-init.c:134
>> #14 0x00007ffff7ddb6ea in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
>> #15 0x0000000000000001 in ?? ()
>> #16 0x00007fffffffdf9f in ?? ()
>> #17 0x0000000000000000 in ?? ()
>>
>> => the same error as when corebase is configured with the objc-bridge
>> enabled and linked with another objc runtime.
>>
>>
>> Hope this can help ...
>>
>> Benoit
>>
>>
>> Le 26/05/2012 17:49, Stefan Bidi a écrit :
>>> Thanks for the running the tests.  I'm in the process of tracking this
>>> down.  I don't have libobjc2 installed in any of my PCs so it becomes
>>> a bit of a problem, but I've gotten with David since he might know
>>> something I don't about libobjc2.
>>>
>>> On Sat, May 26, 2012 at 10:42 AM, Benoît Garrigues <bgarrigues@gmail.com> 
>>> wrote:
>>>> Hi Stef,
>>>>
>>>> I tested revision 35163 on Ubuntu 12.04 64bits with
>>>> - clang 3.0 (from ubuntu)
>>>> - gnustep libobjc2 1.6.
>>>> - gnustep base 1.24
>>>>
>>>>
>>>> First, there are some warnings at compile time :
>>>>
>>>>  Compiling file CFLocale.c ...
>>>> CFLocale.c:312:19: warning: result of comparison against a string literal 
>>>> is
>>>> unspecified (use strncmp instead) [-Wstring-compare]
>>>>       if (context == (const void*)ICU_CALENDAR_KEY)
>>>>                   ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> CFLocale.c:329:19: warning: result of comparison against a string literal 
>>>> is
>>>> unspecified (use strncmp instead) [-Wstring-compare]
>>>>       if (context == (const void*)ICU_CALENDAR_KEY)
>>>>                   ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> 2 warnings generated.
>>>>
>>>>  Compiling file NSCFError.m ...
>>>> NSCFError.m:48:10: warning: incompatible pointer types returning
>>>> 'CFErrorRef' (aka 'NSError *') from a function with result type
>>>>       'NSCFError *' [-Wincompatible-pointer-types]
>>>>   return CFErrorCreate (NULL, domain, code, userInfo);
>>>>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> 1 warning generated.
>>>>
>>>>
>>>>
>>>> Tests results : all tests have compilation warnings and most of them 
>>>> produce
>>>> a core dump.
>>>>
>>>>
>>>> $ make check
>>>> This is gnustep-make 2.6.2. Type 'make print-gnustep-make-help' for help.
>>>> Making check in Source ...
>>>> make[1]: Rien à faire pour « check ».
>>>> Making check in Tests ...
>>>> Checking for presence of test subdirectories ...
>>>> --- Running tests in CFArray ---
>>>>
>>>> CFArray/create.m:
>>>> Failed file:     create.m aborted without running all tests!
>>>>
>>>> CFArray/mutablearray.m:
>>>> Failed file:     mutablearray.m aborted without running all tests!
>>>> --- Running tests in CFAttributedString ---
>>>>
>>>> CFAttributedString/general.m:
>>>> Failed file:     general.m aborted without running all tests!
>>>>
>>>> CFAttributedString/mutable.m:
>>>> Failed file:     mutable.m aborted without running all tests!
>>>> --- Running tests in CFBinaryHeap ---
>>>>
>>>> CFBinaryHeap/general.m:
>>>> Failed file:     general.m aborted without running all tests!
>>>> --- Running tests in CFCalendar ---
>>>>
>>>> CFCalendar/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>>
>>>> CFCalendar/create.m:
>>>> Failed file:     create.m aborted without running all tests!
>>>> --- Running tests in CFCharacterSet ---
>>>>
>>>> CFCharacterSet/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>>
>>>> CFCharacterSet/mutable.m:
>>>> Failed file:     mutable.m aborted without running all tests!
>>>> --- Running tests in CFData ---
>>>>
>>>> CFData/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>> --- Running tests in CFDate ---
>>>>
>>>> CFDate/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>> --- Running tests in CFDateFormatter ---
>>>>
>>>> CFDateFormatter/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>> --- Running tests in CFLocale ---
>>>>
>>>> CFLocale/create.m:
>>>> Failed file:     create.m aborted without running all tests!
>>>>
>>>> CFLocale/displayvalues.m:
>>>> Failed build:
>>>>
>>>> CFLocale/identifier.m:
>>>> Failed build:
>>>>
>>>> CFLocale/values.m:
>>>> Failed file:     values.m aborted without running all tests!
>>>> --- Running tests in CFNumber ---
>>>>
>>>> CFNumber/general.m:
>>>> Failed file:     general.m aborted without running all tests!
>>>> --- Running tests in CFNumberFormatter ---
>>>>
>>>> CFNumberFormatter/create.m:
>>>> Failed file:     create.m aborted without running all tests!
>>>>
>>>> CFNumberFormatter/format.m:
>>>> Failed build:
>>>>
>>>> CFNumberFormatter/parse.m:
>>>> Failed file:     parse.m aborted without running all tests!
>>>> --- Running tests in CFRuntime ---
>>>>
>>>> CFRuntime/runtime.m:
>>>> Failed file:     runtime.m aborted without running all tests!
>>>> --- Running tests in CFString ---
>>>>
>>>> CFString/create.m:
>>>> Failed build:
>>>>
>>>> CFString/encodings.m:
>>>> Failed file:     encodings.m aborted without running all tests!
>>>>
>>>> CFString/format.m:
>>>> Failed build:
>>>>
>>>> CFString/general.m:
>>>> Failed file:     general.m aborted without running all tests!
>>>>
>>>> CFString/mutablestring.m:
>>>> Failed build:
>>>> --- Running tests in CFTimeZone ---
>>>>
>>>> CFTimeZone/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>>
>>>> CFTimeZone/general.m:
>>>> Failed file:     general.m aborted without running all tests!
>>>> --- Running tests in CFTree ---
>>>>
>>>> CFTree/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>> --- Running tests in CFURL ---
>>>>
>>>> CFURL/create.m:
>>>> Failed file:     create.m aborted without running all tests!
>>>>
>>>> CFURL/escaping.m:
>>>> Failed build:
>>>>
>>>> CFURL/file_system_path.m:
>>>> Failed file:     file_system_path.m aborted without running all tests!
>>>>
>>>> CFURL/ref_resolution.m:
>>>> Failed build:
>>>> --- Running tests in CFURLAccess ---
>>>>
>>>> CFURLAccess/basic.m:
>>>> Failed file:     basic.m aborted without running all tests!
>>>> --- Running tests in CFUUID ---
>>>>
>>>> CFUUID/create.m:
>>>> Failed file:     create.m aborted without running all tests!
>>>>
>>>>      27 Failed files
>>>>       8 Failed builds
>>>>
>>>>
>>>>
>>>> When launching CFArray/create test with gdb, the backtrace is the following
>>>> :
>>>>
>>>> Starting program:
>>>> /home/benoit/Projets/OpenSource/objc/GNUstep-anonymous/dev-libs/corebase/Tests/CFArray/obj/create
>>>> [Thread debugging using libthread_db enabled]
>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>> Loading two versions of Protocol.  The class that will be used is undefined
>>>> Loading two versions of Object.  The class that will be used is undefined
>>>> [New Thread 0x7ffff235f700 (LWP 26352)]
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x00007ffff708d687 in objc_msg_lookup_sender () from
>>>> /usr/local/lib/libobjc.so.4
>>>> (gdb) bt
>>>> #0  0x00007ffff708d687 in objc_msg_lookup_sender () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #1  0x00007ffff7931142 in GSPrivateBuildStrings () at
>>>> /home/benoit/src/gnustep-base-1.24.0/Source/externs.m:239
>>>> #2  0x00007ffff7869cc3 in +[NSObject initialize] (self=<optimized out>,
>>>> _cmd=<optimized out>) at
>>>> /home/benoit/src/gnustep-base-1.24.0/Source/NSObject.m:1142
>>>> #3  0x00007ffff70844c4 in objc_send_initialize () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #4  0x00007ffff70842b1 in objc_send_initialize () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #5  0x00007ffff708d792 in objc_msg_lookup_sender () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #6  0x00007ffff72d1807 in NSCFInitialize () at NSCFType.m:51
>>>> #7  0x00007ffff70823c6 in objc_send_load_message () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #8  0x00007ffff7082ee7 in objc_resolve_class () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #9  0x00007ffff7082fc3 in objc_resolve_class_links () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #10 0x00007ffff7086e97 in __objc_exec_class () from
>>>> /usr/local/lib/libobjc.so.4
>>>> #11 0x00007ffff7de9306 in call_init (l=<optimized out>, argc=1,
>>>> argv=0x7fffffffdc68, env=0x7fffffffdc78) at dl-init.c:85
>>>> #12 0x00007ffff7de93df in call_init (env=<optimized out>, argv=<optimized
>>>> out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:52
>>>> #13 _dl_init (main_map=0x7ffff7ffe2c8, argc=1, argv=0x7fffffffdc68,
>>>> env=0x7fffffffdc78) at dl-init.c:134
>>>> #14 0x00007ffff7ddb6ea in _dl_start_user () from 
>>>> /lib64/ld-linux-x86-64.so.2
>>>> #15 0x0000000000000001 in ?? ()
>>>> #16 0x00007fffffffdf8d in ?? ()
>>>> #17 0x0000000000000000 in ?? ()
>>>>
>>>>
>>>> The test.log file is attached.
>>>>
>>>>
>>>> Best regards,
>>>> Benoît
>>>>
>>>>
>>>> Le 21/05/2012 17:42, Stefan Bidi a écrit :
>>>>
>>>> For those of you not familiar with the project, the GNUstep-corebase 
>>>> project
>>>> is a free software implementation of the CoreFoundation library.
>>>>
>>>> I plan on making a release of GNUstep-corebase in a few weeks.  Since this
>>>> is the first release, and the code is still alpha quality at best, I have
>>>> decided to do a prolonged testing phase.  This testing phase will be split
>>>> in 2 subphases.
>>>>
>>>> The first will be a 3 week period, ending June 10th.  This will be the time
>>>> to test the code and look for inconsistencies.  Essentially, I want to make
>>>> sure the code compiles in your favorite platform and all tests pass.  New
>>>> tests can be added to the existing CF-types only, there is no plans to add
>>>> another type/class before the release.  I will still be doing some work on
>>>> the library at this time, but do not plan on adding anything new.
>>>>
>>>> The second phase will end on June 24th and will lead to the release.  This
>>>> is your normal code freeze.  I'd like to get the bugs that were found 
>>>> during
>>>> the previous phase corrected during this time if they were not already
>>>> fixed.  I really do not want to add any new tests at this stage unless it 
>>>> is
>>>> something that can be easily fixed.  Anything requiring a deeper look will
>>>> be postponed to the next release.
>>>>
>>>> To build -corebase you will need gnustep-make, gnustep-base, libobjc, 
>>>> libicu
>>>> and the zoneinfo directory.  The dependency on gnustep-base and libobjc 
>>>> will
>>>> be optional at the time of release.  Being a pure C library, corebase
>>>> doesn't need these libraries unless you want to interface with the objc
>>>> runtime (ie toll-free bridged classes).  I have not decided what to do with
>>>> libicu at this point since it provides core functionality.  If there is
>>>> enough demand, it will be optional as well.
>>>>
>>>> Adam, would you be able to make the release during the week of June 24th?  
>>>> I
>>>> can move the dates around if you need me to.
>>>>
>>>> Thanks
>>>> Stef
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnustep mailing list
>>>> Discuss-gnustep@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnustep mailing list
>>>> Discuss-gnustep@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>>>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]