To follow up on this very old thread.. John.. I'm not sure if you ended
up recreating that work you said you would, but didn't want to bother
you... Another guy on our team started to take the port up again
recently.. Some of the missing functions are now available in our
snv_107 based zone so that took care of a few things...

Current patches and status are here
http://bugs.osunix.org/browse/OSUNIX-44

It's not done and I think there's a few sticky points left.. For example
the building of gnu ld.. and also the gnu as + gcc being needed for
64bit code..

Anyway.. if anyone wants to take a quick look at the patch, give a quick
tip or helping hand we'd most appreciate it.

Cheers,

./Christopher


OSUNIX - Community based OpenSolaris
#ospkg irc.freenode.net

Search Discussions

  • John Martin at Jan 27, 2009 at 10:19 pm

    C. Bergstr?m wrote:
    To follow up on this very old thread.. John.. I'm not sure if you ended
    up recreating that work you said you would, but didn't want to bother
    you... Another guy on our team started to take the port up again
    recently.. Some of the missing functions are now available in our
    snv_107 based zone so that took care of a few things...

    Current patches and status are here
    http://bugs.osunix.org/browse/OSUNIX-44

    It's not done and I think there's a few sticky points left.. For example
    the building of gnu ld.. and also the gnu as + gcc being needed for
    64bit code..

    Anyway.. if anyone wants to take a quick look at the patch, give a quick
    tip or helping hand we'd most appreciate it.
    This biggest headache I had doing the port was asprintf()/vasprintf().
    There was a lot of code that used these functions. Once we have this
    with b107,
    it will make things a lot easier.
  • Joerg Schilling at Jan 27, 2009 at 10:52 pm

    John Martin wrote:

    This biggest headache I had doing the port was asprintf()/vasprintf().
    There was a lot of code that used these functions. Once we have this
    with b107,
    it will make things a lot easier.
    With the private format() based printf() implementation I have in libschily,
    an implementation of the a*print*() functions is simple and can be done in 10
    minutes.

    J?rg

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
  • John Martin at Jan 27, 2009 at 10:59 pm

    Joerg Schilling wrote:
    John Martin wrote:

    This biggest headache I had doing the port was asprintf()/vasprintf().
    There was a lot of code that used these functions. Once we have this
    with b107,
    it will make things a lot easier.
    With the private format() based printf() implementation I have in libschily,
    an implementation of the a*print*() functions is simple and can be done in 10
    minutes.
    I wrote my own also, but that was the trivial part of the work.
    It was the header and library issues, changing the build environment
    in a way that wouldn't break other platforms and would allow
    the official versions of asprintf()/vasprintf() to be used once they
    were delivered.
  • Christopher Bergström at Jan 28, 2009 at 8:39 am

    John Martin wrote:
    Joerg Schilling wrote:
    John Martin wrote:

    This biggest headache I had doing the port was asprintf()/vasprintf().
    There was a lot of code that used these functions. Once we have
    this with b107,
    it will make things a lot easier.
    With the private format() based printf() implementation I have in
    libschily,
    an implementation of the a*print*() functions is simple and can be
    done in 10 minutes.
    I wrote my own also, but that was the trivial part of the work.
    It was the header and library issues, changing the build environment
    in a way that wouldn't break other platforms and would allow
    the official versions of asprintf()/vasprintf() to be used once they
    were delivered.
    J?rg,

    Thanks a lot for letting me know this.. I'm not sure it's something we
    can send upstream, but maybe the open64 guys can make a suggestion? I'd
    much rather link/use maintained code instead of the roll-your-own
    approach for every missing function.. Almost as soon as snv_107 was
    tagged we started the port. It's been a TODO item for a while and I
    actually have license compatible implementations of
    asprintf()/vasprintf()wasprintf()/wvasprintf() functions.. not to
    mention they were in libast iirc.. Anyway.. like I said in the other
    email.. I have to get a new build log so we can hunt for errors and then
    I'll ask very specific things.

    Cheers,

    ./C
  • Joerg Schilling at Jan 28, 2009 at 10:00 am

    "C. Bergstr?m" wrote:

    Thanks a lot for letting me know this.. I'm not sure it's something we
    can send upstream, but maybe the open64 guys can make a suggestion? I'd
    much rather link/use maintained code instead of the roll-your-own
    approach for every missing function.. Almost as soon as snv_107 was
    printf() is a major problem for extended portability of software.
    Larger project groups that like to support a high portability level
    all seem to have own printf implementations in their portability frame work.
    My implementation has the advantage of being cleanly portable and without
    being bound to stdio. In the mid 1980s when other people had problems to
    port csh because of it's own stdio-less printf() written in VAX asembler,
    it took me 10 minutes to relace the implementation by something portable ;-)
    tagged we started the port. It's been a TODO item for a while and I
    actually have license compatible implementations of
    asprintf()/vasprintf()wasprintf()/wvasprintf() functions.. not to
    mention they were in libast iirc.. Anyway.. like I said in the other
    email.. I have to get a new build log so we can hunt for errors and then
    my code is under CDDL. David Korn has it's own portability world that
    although it is different in many places is based on mainly the same
    ideas for portability.

    If you e.g. don't know whether a local printf() supports %j %z or %t
    you save time in the long run if you have your own printf() with you.


    J?rg

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
  • Christopher Bergström at Jan 29, 2009 at 12:42 am

    Joerg Schilling wrote:
    "C. Bergstr?m" wrote:

    Thanks a lot for letting me know this.. I'm not sure it's something we
    can send upstream, but maybe the open64 guys can make a suggestion? I'd
    much rather link/use maintained code instead of the roll-your-own
    approach for every missing function.. Almost as soon as snv_107 was
    printf() is a major problem for extended portability of software.
    Larger project groups that like to support a high portability level
    all seem to have own printf implementations in their portability frame work.
    My implementation has the advantage of being cleanly portable and without
    being bound to stdio. In the mid 1980s when other people had problems to
    port csh because of it's own stdio-less printf() written in VAX asembler,
    it took me 10 minutes to relace the implementation by something portable ;-)

    tagged we started the port. It's been a TODO item for a while and I
    actually have license compatible implementations of
    asprintf()/vasprintf()wasprintf()/wvasprintf() functions.. not to
    mention they were in libast iirc.. Anyway.. like I said in the other
    email.. I have to get a new build log so we can hunt for errors and then
    my code is under CDDL. David Korn has it's own portability world that
    although it is different in many places is based on mainly the same
    ideas for portability.

    If you e.g. don't know whether a local printf() supports %j %z or %t
    you save time in the long run if you have your own printf() with you.

    I think h3sp4wn has made good progress..

    Here's the latest build log..
    http://bugs.osunix.org/secure/attachment/10009/open64-build-log-28-01-2009


    I just glanced at it, but looks like Elf32_Word and friends is undefined..

    ../include/elf_stuff.h:57:23: warning: sys/cdefs.h: No such file or
    directory

    pm me if you'd like access to the env to help or look around.

    ./C
  • Joerg Schilling at Jan 29, 2009 at 11:36 am

    "C. Bergstr?m" wrote:

    I think h3sp4wn has made good progress..

    Here's the latest build log..
    http://bugs.osunix.org/secure/attachment/10009/open64-build-log-28-01-2009


    I just glanced at it, but looks like Elf32_Word and friends is undefined..

    ../include/elf_stuff.h:57:23: warning: sys/cdefs.h: No such file or
    directory
    sys/cdefs.h is a nonstandard include file (not mentioned in either POSIX or
    ANSI-C), it is specific to e.g. FreeBSD.

    Portable software doesn't depend on this file.

    I recommend to look into the file on FreBSD.

    J?rg

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
  • John Martin at Jan 29, 2009 at 1:04 pm

    C. Bergstr?m wrote:

    I just glanced at it, but looks like Elf32_Word and friends is
    undefined..

    ../include/elf_stuff.h:57:23: warning: sys/cdefs.h: No such file or
    directory

    pm me if you'd like access to the env to help or look around.
    This is in the linux include directory. Did you create a directory for
    Solaris (.../osprey/sunos/include/...)?
  • Christopher Bergström at Feb 22, 2009 at 11:57 am

    On Thu, Jan 29, 2009 at 3:04 PM, John Martin wrote:
    C. Bergstr?m wrote:

    I just glanced at it, but looks like Elf32_Word and friends is undefined..

    ../include/elf_stuff.h:57:23: warning: sys/cdefs.h: No such file or
    directory

    pm me if you'd like access to the env to help or look around.
    This is in the linux include directory. Did you create a directory for
    Solaris (.../osprey/sunos/include/...)?
    Hi John/everyone

    I don't understand the question about creating osprey/sunos/include/..
    but here's my env and exactly what I'm doing..

    gcc -v
    Using built-in specs.
    Target: i386-pc-solaris2.11
    Configured with: ./configure --prefix=/opt/gcc/gcc-4.4
    --with-as=/usr/local/src/usr/sfw/bin/gas --with-gnu-as
    --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
    --enable-shared --with-mpfr-include=/usr/include/mpfr
    --with-gmp-include=/usr/include/gmp LDFLAGS=-lgmp
    Thread model: posix
    gcc version 4.4.0 20090130 (experimental) (GCC)
    (Can I build open64 with gcc-4.4?)

    open64 trunk + http://pkg.osunix.org/open64/open64-opensolaris.diff

    gmake 'LDFLAGS=-L/opt/gcc/gcc-4.4/lib/amd64 -R/opt/gcc/gcc-4.4/lib/amd64'

    Here's a strange warning and the error..

    1)
    gmake -C osprey/targx8664_x8664/driver
    abort: There is no Mercurial repository here (.hg not found)!

    2)
    gmake[3]: Entering directory `/usr/local/src/open64/osprey/targx8664_x8664/be'
    C++ /usr/local/src/open64/osprey/targx8664_x8664/be/../../be/be/dra_mangle.cxx
    In file included from ../../be/cg/cg.h:46,
    from ../../be/be/dra_mangle.cxx:72:
    ../../be/region/region_util.h:63:53: error: preg_list.h: No such file
    or directory
    In file included from ../../be/cg/cg.h:46,
    from ../../be/be/dra_mangle.cxx:72:
    ../../be/region/region_util.h:231: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:231: error: expected ';' before '*' token
    ../../be/region/region_util.h:232: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:232: error: expected ';' before '*' token
    ../../be/region/region_util.h:237: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:237: error: expected ';' before '*' token
    ../../be/region/region_util.h:238: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:238: error: expected ';' before '*' token
    ../../be/region/region_util.h:520: warning: 'REGION_search_preg_set'
    initialized and declared 'extern'
    ../../be/region/region_util.h:520: error: 'PREG_LIST' was not declared
    in this scope
    ../../be/region/region_util.h:520: error: expected primary-expression
    before ',' token
    ../../be/region/region_util.h:520: error: expected primary-expression
    before ')' token
    ../../be/region/region_util.h:520: error: initializer expression list
    treated as compound expression
    gmake[3]: *** [dra_mangle.o] Error 1

    So why isn't preg_list.h being generated... /usr/xpg4/bin is ahead of
    /usr/bin in the path...

    Thanks..

    ./C
  • Jian-Xin Lai at Feb 22, 2009 at 2:23 pm
    For the first problem, we can ignore it at all.
    HG is used by Pathscale Compiler as the version control tool. The HG related
    stuffs are not removed while we merge the Open64 with Pathscale Compiler.

    2009/2/22 Christopher Bergström <cbergstrom@netsyncro.com>
    On Thu, Jan 29, 2009 at 3:04 PM, John Martin wrote:
    C. Bergström wrote:

    I just glanced at it, but looks like Elf32_Word and friends is
    undefined..
    ../include/elf_stuff.h:57:23: warning: sys/cdefs.h: No such file or
    directory

    pm me if you'd like access to the env to help or look around.
    This is in the linux include directory. Did you create a directory for
    Solaris (.../osprey/sunos/include/...)?
    Hi John/everyone

    I don't understand the question about creating osprey/sunos/include/..
    but here's my env and exactly what I'm doing..

    gcc -v
    Using built-in specs.
    Target: i386-pc-solaris2.11
    Configured with: ./configure --prefix=/opt/gcc/gcc-4.4
    --with-as=/usr/local/src/usr/sfw/bin/gas --with-gnu-as
    --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
    --enable-shared --with-mpfr-include=/usr/include/mpfr
    --with-gmp-include=/usr/include/gmp LDFLAGS=-lgmp
    Thread model: posix
    gcc version 4.4.0 20090130 (experimental) (GCC)
    (Can I build open64 with gcc-4.4?)

    open64 trunk + http://pkg.osunix.org/open64/open64-opensolaris.diff

    gmake 'LDFLAGS=-L/opt/gcc/gcc-4.4/lib/amd64 -R/opt/gcc/gcc-4.4/lib/amd64'

    Here's a strange warning and the error..

    1)
    gmake -C osprey/targx8664_x8664/driver
    abort: There is no Mercurial repository here (.hg not found)!

    2)
    gmake[3]: Entering directory
    `/usr/local/src/open64/osprey/targx8664_x8664/be'
    C++
    /usr/local/src/open64/osprey/targx8664_x8664/be/../../be/be/dra_mangle.cxx
    In file included from ../../be/cg/cg.h:46,
    from ../../be/be/dra_mangle.cxx:72:
    ../../be/region/region_util.h:63:53: error: preg_list.h: No such file
    or directory
    In file included from ../../be/cg/cg.h:46,
    from ../../be/be/dra_mangle.cxx:72:
    ../../be/region/region_util.h:231: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:231: error: expected ';' before '*' token
    ../../be/region/region_util.h:232: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:232: error: expected ';' before '*' token
    ../../be/region/region_util.h:237: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:237: error: expected ';' before '*' token
    ../../be/region/region_util.h:238: error: ISO C++ forbids declaration
    of 'PREG_LIST' with no type
    ../../be/region/region_util.h:238: error: expected ';' before '*' token
    ../../be/region/region_util.h:520: warning: 'REGION_search_preg_set'
    initialized and declared 'extern'
    ../../be/region/region_util.h:520: error: 'PREG_LIST' was not declared
    in this scope
    ../../be/region/region_util.h:520: error: expected primary-expression
    before ',' token
    ../../be/region/region_util.h:520: error: expected primary-expression
    before ')' token
    ../../be/region/region_util.h:520: error: initializer expression list
    treated as compound expression
    gmake[3]: *** [dra_mangle.o] Error 1

    So why isn't preg_list.h being generated... /usr/xpg4/bin is ahead of
    /usr/bin in the path...

    Thanks..

    ./C


    ------------------------------------------------------------------------------
    Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
    CA
    -OSBC tackles the biggest issue in open source: Open Sourcing the
    Enterprise
    -Strategies to boost innovation and cut costs with open source
    participation
    -Receive a $600 discount off the registration fee with the source code:
    SFAD
    http://p.sf.net/sfu/XcvMzF8H
    _______________________________________________
    Open64-devel mailing list
    Open64-devel@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/open64-devel


    --
    Regards,
    Lai Jian-Xin
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/osunix-dev/attachments/20090222/d3025a2e/attachment.htm
  • Christopher Bergström at Feb 22, 2009 at 2:31 pm
    apologies for the noise.. preg_list.* wasn't being generated correctly
    because of ksh93.. Using bash as the shell and I get progress..

    Next issue I hit...

    BUILD_OS seems like it's still defined as LINUX.. changing that to
    SUNOS == unhappy.. (What's the cleanest way to add this?)

    looking at elf_stuff.h and it appears it's not being generated correctly..

    Error below..
    ----------

    C++ /usr/local/src/open64/osprey/targx8664_x8664/be/../../be/com/ipa_lno_file.cxx
    ../../be/com/ipa_lno_file.cxx:40:1: warning: "__STDC_LIMIT_MACROS" redefined
    <command-line>: warning: this is the location of the previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:73:1: warning: "EI_NIDENT" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:63:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:153:1: warning: "EM_PARISC" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:163:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:160:1: warning: "EM_ALPHA" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:190:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:453:1: warning: "SHT_HIUSER" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:438:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:457:1: warning: "SHF_WRITE" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:440:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:458:1: warning: "SHF_ALLOC" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:441:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:459:1: warning: "SHF_EXECINSTR" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:442:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:473:1: warning: "ELF32_ST_BIND" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:506:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:474:1: warning: "ELF32_ST_TYPE" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:507:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:475:1: warning: "ELF32_ST_INFO" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:508:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:478:1: warning: "ELF64_ST_BIND" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:510:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:479:1: warning: "ELF64_ST_TYPE" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:511:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:480:1: warning: "ELF64_ST_INFO" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:512:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:563:1: warning: "ELF32_R_SYM" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:590:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:564:1: warning: "ELF32_R_TYPE" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:591:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:565:1: warning: "ELF32_R_INFO" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:592:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:567:1: warning: "ELF64_R_SYM" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:594:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:568:1: warning: "ELF64_R_TYPE" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:595:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:584:1: warning: "PF_X" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:346:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:585:1: warning: "PF_W" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:345:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:586:1: warning: "PF_R" redefined
    In file included from /usr/include/elf.h:31,
    from ../../be/com/ipa_lno_file.cxx:53:
    /usr/include/sys/elf.h:344:1: warning: this is the location of the
    previous definition
    In file included from ../../be/com/ipa_lno_file.cxx:72:
    ../include/elf_stuff.h:67: error: expected constructor, destructor, or
    type conversion before 'typedef'
    In file included from ../../be/com/ipa_lno_file.cxx:73:
    ../../common/com/pu_info.h:132: error: expected constructor,
    destructor, or type conversion before 'typedef'
    gmake[3]: *** [ipa_lno_file.o] Error 1
    gmake[3]: Leaving directory `/usr/local/src/open64/osprey/targx8664_x8664/be'
  • Rayson Ho at Jan 28, 2009 at 8:22 am

    On Tue, Jan 27, 2009 at 4:43 PM, "C. Bergstr?m" wrote:
    Current patches and status are here
    http://bugs.osunix.org/browse/OSUNIX-44
    Chris, that's really good progress... And BTW, I took a very quick
    look at the open64-solaris6.diff patch -- is it all that's needed to
    get the open64 compiler binary?

    It's not done and I think there's a few sticky points left.. For example the
    building of gnu ld.. and also the gnu as + gcc being needed for 64bit code..
    Not sure when exactly GNU as & ld are needed... If you can get Open64
    to translate C code into assembly language code, then the port should
    be "done" -- as the assemble step and the link step are almost
    idential to those of gcc on Solaris.

    And gas & ld should "just" work on Solaris, since the AMD64 ELF ABI is
    same on Solaris AMD64 and Linux AMD64 (and IIRC, FreeBSD ELF on
    AMD64). In fact, a few months ago I did the experiment of generating
    object files on Linux and linking them on Solaris.

    I googled for gcc solaris m64 amd64, there are some minor gcc build
    problems on Solaris, but none of them fatal.

    Even more interesting is that someone tried to bootstrap gcc to get a
    64-bit gcc binary:

    http://gcc.gnu.org/ml/gcc-help/2008-12/msg00196.html

    Anyway.. if anyone wants to take a quick look at the patch, give a quick tip
    or helping hand we'd most appreciate it.
    While I have experience with porting compilers, I have never ported
    linkers and assemblers. However, I am happy to look at it if we can
    break down the Open64 Solaris port into manageable work items :-P

    Rayson

    Cheers,

    ./Christopher


    OSUNIX - Community based OpenSolaris
    #ospkg irc.freenode.net
  • Christopher Bergström at Jan 28, 2009 at 8:32 am

    Rayson Ho wrote:
    On Tue, Jan 27, 2009 at 4:43 PM, "C. Bergstr?m"
    wrote:
    Current patches and status are here
    http://bugs.osunix.org/browse/OSUNIX-44
    Chris, that's really good progress... And BTW, I took a very quick
    look at the open64-solaris6.diff patch -- is it all that's needed to
    get the open64 compiler binary?
    Hi Rayson,

    h3sp4wn has been the one working on this, but I can give you access to a
    cloned working environment any time someone wants to check it out.
    After the port is /done/ we'll package it and start using it as our
    default c++ compiler and start testing the c code generation.
    It's not done and I think there's a few sticky points left.. For example the
    building of gnu ld.. and also the gnu as + gcc being needed for 64bit code..
    Not sure when exactly GNU as & ld are needed... If you can get Open64
    to translate C code into assembly language code, then the port should
    be "done" -- as the assemble step and the link step are almost
    idential to those of gcc on Solaris.

    And gas & ld should "just" work on Solaris, since the AMD64 ELF ABI is
    same on Solaris AMD64 and Linux AMD64 (and IIRC, FreeBSD ELF on
    AMD64). In fact, a few months ago I did the experiment of generating
    object files on Linux and linking them on Solaris.

    I googled for gcc solaris m64 amd64, there are some minor gcc build
    problems on Solaris, but none of them fatal.

    Even more interesting is that someone tried to bootstrap gcc to get a
    64-bit gcc binary:

    http://gcc.gnu.org/ml/gcc-help/2008-12/msg00196.html
    I'd have to confirm, but he's been building gcc all sorts of ways and
    would know best..
    Anyway.. if anyone wants to take a quick look at the patch, give a quick tip
    or helping hand we'd most appreciate it.
    While I have experience with porting compilers, I have never ported
    linkers and assemblers. However, I am happy to look at it if we can
    break down the Open64 Solaris port into manageable work items :-P
    I'll have to toss this in the build queue.. upload a new log and check
    for errors.. From there we'll have an absolute list of errors we can
    break down.

    ./C

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouposunix-dev @
categoriesopensolaris
postedJan 27, '09 at 9:43p
activeFeb 22, '09 at 2:31p
posts14
users5
websiteopensolaris.org

People

Translate

site design / logo © 2018 Grokbase