Crossbridge and C++11


I try to implement an external library in C++11 using Crossbridge 1.1.0 on Mac but it’s not finalized and I have this error :

/Users/user/Desktop/Projets/crossbridge/flascc/sdk/usr/bin/…/…/usr/lib/libc.a: error: undefined reference to ‘__openat’
/Users/user/Desktop/Projets/crossbridge/flascc/sdk/usr/bin/…/…/usr/lib/libc.a: error: undefined reference to ‘_fstatat’
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [T05] Error 1


1 Like

the thing is you would have to port all CrossBridge to C++ 11 first

in short , either you downport your lib to the level of C++ CrossBridge support which is C++ 98 (or was it C++ 03?) if I remember well

or the opposite

in any case it would end up being a port of something which can be time consuming
some people even say that C++ 11 feels like a different language than C++

here few posts

The Biggest Changes in C++11 (and Why You Should Care)

porting the C++ of CrossBridge to C++ 11 is not a small job imho
it could be hard to validate the changes are not breaking anything


I didn’t pay attention to the error message you throw like that without context (your fault)
but yeah those are not C++ 11 errors, the OS where you are compiling do not have those defintions

see openat
int openat(int fd, const char *path, int oflag, ...);

and fstatat
int fstatat(int fd, const char *restrict *path*, struct stat *restrict *buf* , int *flag* );

so for one the library you are using is probably only for Linux and not made to compile under Windows, etc.

so yeah some pedantic arrogant asshat decided to support C++ 11 because it is so modern
but then make its source code not portable by using some specific definitions

or see for ex
where you can read

       The  fstatat()  system call operates in exactly the same way as stat(),
       except for the differences described here.

       If the pathname given in pathname is relative, then it  is  interpreted
       relative  to  the  directory  referred  to by the file descriptor dirfd
       (rather than relative to the current working directory of  the  calling
       process, as is done by stat() for a relative pathname).

       If  pathname  is relative and dirfd is the special value AT_FDCWD, then
       pathname is interpreted relative to the current  working  directory  of
       the calling process (like stat()).

       If pathname is absolute, then dirfd is ignored.

       flags  can  either  be 0, or include one or more of the following flags

       AT_EMPTY_PATH (since Linux 2.6.39)
              If pathname is an empty string, operate on the file referred  to
              by  dirfd (which may have been obtained using the open(2) O_PATH
              flag).  If dirfd is AT_FDCWD, the call operates on  the  current
              working directory.  In this case, dirfd can refer to any type of
              file, not just a directory.  This flag is Linux-specific; define
              _GNU_SOURCE to obtain its definition.

       AT_NO_AUTOMOUNT (since Linux 2.6.38)
              Don't  automount the terminal ("basename") component of pathname
              if it is a directory that is an automount  point.   This  allows

       See openat(2) for an explanation of the need for fstatat().

and see

   Rationale for openat() and other directory file descriptor APIs
       openat() and the other system calls and library functions that  take  a
       directory  file  descriptor  argument (i.e., execveat(2), faccessat(2),
       fanotify_mark(2), fchmodat(2), fchownat(2),  fstatat(2),  futimesat(2),
       linkat(2), mkdirat(2), mknodat(2), name_to_handle_at(2), readlinkat(2),
       renameat(2), symlinkat(2), unlinkat(2), utimensat(2), mkfifoat(3),  and
       scandirat(3))  are supported for two reasons.  Here, the explanation is
       in terms of the openat() call, but the rationale is analogous  for  the
       other interfaces.

       First,  openat()  allows  an  application to avoid race conditions that
       could occur when using open() to open files in directories  other  than
       the  current  working directory.  These race conditions result from the
       fact that some component of the directory prefix given to open()  could
       be  changed in parallel with the call to open().  Suppose, for example,
       that we wish to create the file path/to/xxx.dep if the file path/to/xxx
       exists.   The  problem is that between the existence check and the file
       creation step, path or to (which might be symbolic links) could be mod-
       ified  to  point to a different location.  Such races can be avoided by
       opening a file descriptor for the target directory, and then specifying
       that file descriptor as the dirfd argument of (say) fstatat(2) and ope-

I could tell you why this happen but I’m not gonna do that

I’ll stop here because you don’t give any context and just drop some error messages, honestly … I’m tired with that, you want help? then fucking provide context or GTFO

What library are you trying to implement?

I try to implement Artistic Style 3.1 on Mac OS X Mojave
I implemented correctly Artistic Style 2.06 but the version 3.1 need C++11
the code in make file

“/Users/user/Desktop/Projets/crossbridge/flascc/sdk/usr/bin/clang++” -std=c++11 -Wno-write-strings -Wno-trigraphs -O4 as3api.cpp ASBeautifier.cpp ASEnhancer.cpp ASFormatter.cpp ASLocalizer.cpp ASResource.cpp astyle_main.cpp -emit-swc=com.utils.astyle -o astyleCPP.swc

but what are you trying to do ? and how and where etc…

use this library to format code, it’s the first line here.
If you don’t want to help, fine.

and this library provide pre-compiled executables and you can use the NativeProcess class

here what is missing on your side

  • which CrossBridge are you using ?
    the official one or the community one ?
  • do you understand how CrossBridge works ?
    when you use this path /Users/user/Desktop/Projets/crossbridge/flascc/sdk/usr/bin/clang++
    it seems you try to run it from sources instead of installing CrossBridge and
    run it from the install folder eg. $(FLASCC)/usr/bin/g++ / $(FLASCC)/usr/bin/gcc
    • which CrossBridge do you use ?
    • how did you install that CrossBridge ?
    • where did you see you could use clang++ instead of gcc and g++ ?
  • using clang toolchain is not really supported
    see Hello world milestion for clang toolchain
  • what’s inside your as3api.cpp ?? it is easy to shoot yourself in the foot with C/C++
  • if you reuse the code from other classes like ASFormatter.cpp etc. you should compile it last
  • you might try the futures branch which seems to bring clang/clang++ support
  • when you use -O4 flag you are stripping all the symbols, try compiling without it
  • try to compile like that
    $(FLASCC)/usr/bin/g++ -std=c++11 -Wno-write-strings -Wno-trigraphs ASBeautifier.cpp ASEnhancer.cpp ASFormatter.cpp ASLocalizer.cpp ASResource.cpp astyle_main.cpp as3api.cpp -emit-swc=com.utils.astyle -o astyleCPP.swc
    OR even try that
    $(FLASCC)/usr/bin/g++ -Wno-write-strings -Wno-trigraphs ASBeautifier.cpp ASEnhancer.cpp ASFormatter.cpp ASLocalizer.cpp ASResource.cpp astyle_main.cpp as3api.cpp -emit-swc=com.utils.astyle -o astyleCPP.swc

I use the future branch, g++ doesn’t support “-std=c++11” argument
I understand how g++ and clang++ work

using Artistic Style 2.06, crossbridge 1.0.1 and g++ it work

I try just the future branch and C++11 but I think it’s not finalized and doesn’t work correctly

there you got your answer