Brendan Heading | 31 Jul 14:44 2015
Picon

Re: [Gc] Compilation issue against musl

Ivan,

Thank you - my apologies, I should have checked the master branch on
github. I tested the changes from there and they appear to solve the
problem.

Do you have any plans to issue a new release in the near future ?

regards

Brendan

On 31 July 2015 at 09:40, Ivan Maidanski <ivmai <at> mail.ru> wrote:
> Hi,
>
> Please check master branch. Issue should be solved.
> Also, there are a couple of issues in github bdwgc bug tracker, please check
> them.
>
> --
>
> среда, 29 июля 2015г., 02:31 +03:00 от Brendan Heading
> <brendanheading <at> gmail.com>:
>
> Hi guys,
>
> There's a minor compilation issue when building bdwgc against musl. The
> problem is observed on version 7.4.2. The compilation error is as follows :
>
> =================
(Continue reading)

Brendan Heading | 29 Jul 01:31 2015
Picon

[Gc] Compilation issue against musl

Hi guys, 

There's a minor compilation issue when building bdwgc against musl. The problem is observed on version 7.4.2. The compilation error is as follows : 

=================
In file included from os_dep.c:44:0: /home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/asm/sigcontext.h:9:8: error: redefinition of 'struct sigcontext' struct sigcontext { ^ In file included from /home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/signal.h:243:0, from ./include/private/../gc_pthread_redirects.h:42, from ./include/private/../gc.h:1443, from ./include/private/gc_priv.h:46, from os_dep.c:17: /home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/bits/signal.h:11:16: note: originally defined here typedef struct sigcontext=================
The root cause is in the following excerpt from os_dep.c
=================#   if 2 <= __GLIBC__#     if 2 == __GLIBC__ && 0 == __GLIBC_MINOR__        /* glibc 2.1 no longer has sigcontext.h.  But signal.h          */        /* has the right declaration for glibc 2.1.                     */#       include <sigcontext.h>#     endif /* 0 == __GLIBC_MINOR__ */#   else /* __GLIBC__ < 2 */      /* libc5 doesn't have <sigcontext.h>: go directly with the kernel   */      /* one.  Check LINUX_VERSION_CODE to see which we should reference. */#     include <asm/sigcontext.h>#   endif /* __GLIBC__ < 2 */=================The logic here is intended to provide two special cases; one for __GLIBC__ version 2.0, the other is a fall through case intended to be reached if __GLIBC__ version is <2. However this fall through is also reached if __GLIBC__ is undefined as is the case in musl. If the __GLIBC__ version is 2.1 or greater no special action is taken.musl, as a matter of policy, will never provide a macro to detect its presence. Instead I propose that the above logic be wrapped in an #ifdef __GLIBC__. I've tested that this allows the build to work on musl, and should also work on uclibc and other C libraries. I've attached a patch - I'm more than happy to update it if you feel there is a better approach. regardsBrendan






_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Bryan Christianson | 29 Jul 03:38 2015

[Gc] Compilation fails on AIX-7.1

I’m trying to build gc-7.4.2 and libatomic_ops-7.4.2 on aix-7.1 and not having much luck.

Using gcc-4.9.1,  I followed the build instructions at http://www.hboehm.info/gc/#where

I suspect I need to set environment variables and/or pass aix specific options to the configure script.

 

Any help appreciated

 

Regards

Bryan Christianson

 

Compilation fails with

 

depbase=`echo alloc.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\

        /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -Wall -Wextra -g -fno-strict-aliasing -MT alloc.lo -MD -MP -MF $depbase.Tpo -c -o alloc.lo alloc.c &&\

        mv -f $depbase.Tpo $depbase.Plo

libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -Wall -Wextra -g -fno-strict-aliasing -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c alloc.c  -fPIC -DPIC -o .libs/alloc.o

alloc.c:1368:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]

 

a bunch of warnings

..

^

alloc.c: In function 'GC_never_stop_func':

alloc.c:128:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]

}

^

 

 

And then

Assembler:

/tmp//cchA8WDg.s: line 888: 1252-142 Syntax error.

/tmp//cchA8WDg.s: line 890: 1252-142 Syntax error.

/tmp//cchA8WDg.s: line 892: 1252-142 Syntax error.

/tmp//cchA8WDg.s: line 893: 1252-142 Syntax error.

make[1]: *** [alloc.lo] Error 1

make[1]: Leaving directory `/gthome/bryanc/hal/gc/gc-7.4.2'

make: *** [all-recursive] Error 1

 

<!-- p {margin:0cm; margin-bottom:.0001pt} -->

P : Please consider the environment before printing this e-mail

This e-mail together with any attachments is confidential, may be subject to legal privilege and may contain proprietary information, including information protected by copyright. If you are not the intended recipient, please do not copy, use or disclose this e-mail; please notify us immediately by return e-mail and then delete this e-mail. No liability is accepted for unauthorized transmissions or actions arising. Any views or opinions expressed in this e-mail may be solely those of the author and are not necessarily those of Gentrack. This email, if it relates to a specific contract, is sent on behalf of the Gentrack company which entered into the contract. Please contact the sender if you are unsure of the contracting Gentrack company or visit our web page http://www.gentrack.com for further information on the Gentrack Group. Where Gentrack UK Ltd is the company referred to, its details are: Registered in England & Wales No. 08229203. Reg. office: Evergreen House, 160 Euston Road, Grafton, London NW1 2DX.

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Юрий Соколов | 13 Jul 13:12 2015
Picon

[Gc] Strange leak in simple code

Using libgc from Ubuntu 15.04 (7.2b-6.4) this simple code leaks:

#include <gc.h> struct list { struct list* next; }; int main() { GC_INIT(); struct list *last = NULL; for (;;) { struct list* nuo = GC_MALLOC(sizeof(struct list)); nuo->next = NULL; // if next line is commented, then no leakage if (last) last->next = nuo; last = nuo; } }


stackoverflow question http://stackoverflow.com/questions/31380641/libgc-why-this-code-leaks
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Sam Nipps | 11 Jul 21:47 2015
Picon
Picon

[Gc] Bug in build instructions

On the page http://www.hboehm.info/gc/, under the heading "Where to get  
the collector", there is a shell excerpt:

    cd D
    git clone git://github.com/ivmai/libatomic_ops.git
    git clone git://github.com/ivmai/bdwgc.git
    ln -s  D/libatomic_ops D/bdwgc/libatomic_ops
    cd bdwgc
    autoreconf -vif
    automake --add-missing
    ./configure
    make

The fourth line refers to directory D in a relative path, even though the  
first line cd'd into it.

Maybe add a "pushd .." and "popd" around line 4.

Sam Nipps
Ivan Maidanski | 4 Jul 17:59 2015
Picon

[Gc] Fwd: [bdwgc] undefined macro AC_ENABLE_SHARED & AC_PROG_LIBTOOL (#75)

Forwarding to ML

https://github.com/ivmai/bdwgc/issues/75

-------- Forwarded email --------
From: Blake McBride <notifications <at> github.com>
To: ivmai/bdwgc <bdwgc <at> noreply.github.com>
DAte: Fri, 3 Jul 2015, 10:44 -07:00
Subj: [bdwgc] undefined macro AC_ENABLE_SHARED & AC_PROG_LIBTOOL (#75)

On a current LinuxMint 64 with current git version of bdwgc & libatomic_ops:

...
$ autoreconf -vif
autoreconf: Entering directory .'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory libatomic_ops to autoreconf
autoreconf: Entering directorylibatomic_ops'
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:14: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './config.sub'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
src/Makefile.am:5: error: Libtool library used but 'LIBTOOL' is undefined
src/Makefile.am:5: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
src/Makefile.am:5: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
src/Makefile.am:5: If 'LT_INIT' is in 'configure.ac', make sure
src/Makefile.am:5: its definition is in aclocal's search path.
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: automake failed with exit status: 1
$ libtool --version
libtool (GNU libtool) 2.4.2
Written by Gordon Matzigkeit gord <at> gnu.ai.mit.edu, 1996


Reply to this email directly or view it on GitHub.


_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Henryk Michalewski | 18 Mar 01:02 2015
Picon

[Gc] A student assignment based on bdwgc

I am running a CS 101 class at the CS department of the University of
Warsaw. This class is focused on the C language. I like the idea of
making a student software project based on bdwgc  and contemplated
options such as
 - implementation of alternative gc algorithm
 - some optimizations/improvements in the current code
 - building an additional tool conceptually related to bdwgc
The final project should not exceed 2000-3000 lines.

Maybe this is a stupid idea in the sense that in your view this is a
too tough assignment - please feel free to inform me about it.
Otherwise, I would be glad to hear some specific recommendations from
the authors!

Yours, Henryk Michalewski

--

-- 
http://www.mimuw.edu.pl/~henrykm
Ivan Maidanski | 17 Feb 10:48 2015
Picon

Re: [Gc] [bdwgc] Build failed on NetBSD/sparc64, Makefile problem (#65)

Hello Tobias,

Could you please submit a patch for configure.

For historical reasons C files remain in rootdir while others (required only for some targets) are moved to src folder.

--

Mon, 16 Feb 2015, 11:04 +03:00 from Tobias Nygren <notifications <at> github.com>:

Hi,
When building with ./configure && make on NetBSD/sparc64  the build failed with:
>make[1]: don't know how to make sparc_mach_dep.lo. Stop
This fixed the problem:
gc-7.4.2$ mv src/* .
gc-7.4.2$ rmdir src
(Why are the sparc assembler files alone in the src subdirectory?)

Reply to this email directly or  view it on GitHub .

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Andrew Pinski | 11 Feb 07:03 2015
Picon

[Gc] [PATCH] Implement boehm-gc for AARCH64:ILP32

Hi,
  This is a simple patch which allows all of the boehm-gc testsuite
that is included with GCC to pass for AARCH64:ILP32.
Basically we need to set CPP_WORDSZ to 32 and the alignment to 4 so we
detect pointers correctly.

OK for GCC?  Bootstrapped and tested for aarch64-linux-gnu with no
regressions and many libjava testcases now pass.

OK for boehm-gc upstream?  I don't have write access to upstream
sources though, if approved there please apply it also.

Thanks,
Andrew Pinski

GCC ChangeLog:
    * include/private/gcconfig.h (CPP_WORDSZ): Correct for AARCH64:ILP32.
    (ALIGNMENT): Correct for AARCH64:ILP32.
commit 7d15d08c61991c3f7fea822fb567106dde83a166
Author: Andrew Pinski <apinski <at> cavium.com>
Date:   Wed Feb 11 02:35:45 2015 +0000

    Fix boehm-gc for AARCH64:ILP32

    * include/private/gcconfig.h (CPP_WORDSZ): Correct for AARCH64:ILP32.
    (ALIGNMENT): Correct for AARCH64:ILP32.

diff --git a/boehm-gc/include/private/gcconfig.h b/boehm-gc/include/private/gcconfig.h
index 7e081d9..049e24c 100644
--- a/boehm-gc/include/private/gcconfig.h
+++ b/boehm-gc/include/private/gcconfig.h
 <at>  <at>  -1854,9 +1854,14  <at>  <at> 
 # endif

 # ifdef AARCH64
-#   define CPP_WORDSZ 64
 #   define MACH_TYPE "AARCH64"
-#   define ALIGNMENT 8
+#   ifdef __ILP32__
+#     define CPP_WORDSZ 32
+#     define ALIGNMENT 4
+#   else
+#     define CPP_WORDSZ 64
+#     define ALIGNMENT 8
+#   endif
 #   ifndef HBLKSIZE
 #     define HBLKSIZE 4096
 #   endif
diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h
index aa80d53..989a734 100644
--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
 <at>  <at>  -2020,9 +2020,14  <at>  <at> 
 # endif

 # ifdef AARCH64
-#   define CPP_WORDSZ 64
 #   define MACH_TYPE "AARCH64"
-#   define ALIGNMENT 8
+#   ifdef __ILP32__
+#     define CPP_WORDSZ 32
+#     define ALIGNMENT 4
+#   else
+#     define CPP_WORDSZ 64
+#     define ALIGNMENT 8
+#   endif
 #   ifndef HBLKSIZE
 #     define HBLKSIZE 4096
 #   endif
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Tom de Vries | 19 Jan 10:09 2015

[Gc] boehm-gc.c/gctest.c spurious failure

Hi,

FYI, with gcc trunk on x86_64 Linux, I ran into PR64042: 'FAIL: 
boehm-gc.c/gctest.c -O2 execution test'. ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 )

The testcase gctest fails spuriously, a couple of times per 1000 runs.

The failure has been reproduced by others, also on Darwin.

Any information on this is appreciated.

Thanks,
- Tom
Hans Aberg | 2 Jan 23:16 2015
Picon

[Gc] C++ global objects initialization

FYI: C++ global objects initialization on platforms where GC_INIT() is necessary, as on OS X 10.10, there
is the problem that the latter must be called before memory allocations by GC_malloc(). So it can’t be in main().

I found a workaround, that perhaps might be used to avoid GC_INIT() in the API (disregarding complications
with multiple allocators): the GC_malloc() replacement calls a pointer which first is an
initialization function, but is then changed to just the old GC_malloc().

In the code below, the GC_malloc() replacement is called gc_f. Then it seems to work in C++11 with the
operator new() replacements below, also with standard library containers global objects.

----
typedef void* (*malloc_ptr)(size_t);

extern malloc_ptr gc_f;

void* gc_uninitialized(size_t n) {
  gc_f = &GC_malloc;
  GC_INIT();
  return gc_f(n);
}

malloc_ptr gc_f = gc_uninitialized;

void* operator new(std::size_t n) { return gc_f(n); }
void operator delete(void*) noexcept {}
void* operator new[](std::size_t n) { return gc_f(n); }
void operator delete[](void*) noexcept {}
----
_______________________________________________
bdwgc mailing list
bdwgc <at> lists.opendylan.org
https://lists.opendylan.org/mailman/listinfo/bdwgc

Gmane