Opened 3 years ago

Closed 3 years ago

#12952 closed bug (fixed)

Issue Building on MacOS-X w/ DEBUG=1

Reported by: apl-haiku Owned by: bonefish
Priority: normal Milestone: Unscheduled
Component: Build System Version: R1/Development
Keywords: macos-x printchar gnuregex Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

Building with DEBUG=1 on MacOS-X yields an error;

...
Undefined symbols for architecture x86_64:
  "_printchar", referenced from:
      _print_fastmap in regex.o
      _print_partial_compiled_pattern in regex.o
      _print_double_string in regex.o
      _regex_compile in regex.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
...

This is because the host build-targets are requiring "gnuregex" and this library has debug code that looks for a "printchar" function which is not defined.

This patch adds a definition of this function for the purposes of sating the build process.

Attachments (1)

0001-Build-implement-function-so-that-debug-build-of-gnur.patch (1.3 KB ) - added by apl-haiku 3 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by apl-haiku, 3 years ago

Has a Patch: set

comment:2 by pulkomandy, 3 years ago

We could use the implementation from the original regex library, which escapes control codes: https://github.com/ge-ne/bibtool/blob/master/regex-0.12/test/printchar.c

Is there a reason we are using this very old implementation of regex? The GNU page says it has been decomissionned, and the replacement GNU rx also was. They suggest using the new (from 2002) implementation which we can extract from a current glibc, or gnulib.

comment:3 by apl-haiku, 3 years ago

I am a little unclear if it is OK to bring that 'printchar.c' material given its GNU license?

comment:4 by pulkomandy, 3 years ago

So is the regex.c we are using, it comes from the same source. Since this is used only during the build process, it is of no consequences on the generated Haiku system.

comment:5 by apl-haiku, 3 years ago

I guess that it would have an impact for the build-host build products? For example, if anyone were to build "package" for MacOS-X.

Last edited 3 years ago by apl-haiku (previous) (diff)

comment:6 by pulkomandy, 3 years ago

Yes, but libgnuregex is already under the GPL, so using more files from there doesn't change anything. If we want to avoid that, we would need to remove libgnuregex and adjust the code to be compatible with the regex implementation in Mac OS X. Is there a reason to do so, or is it ok if "package" is GPL licensed?

comment:7 by apl-haiku, 3 years ago

The later "glibc" variant you mentioned above appears to be LGPL licensed;

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/regex.c

"haiku/src/build/libgnuregex" builds to a shared library "libgnuregex_build.so" using "BuildPlatformSharedLibrary". As far as my understanding goes, the LGPL allows linking to a shared library without putting licensing requirements on the executable. So this would imply that upgrading to the LGPL variant would be cleaner better path to take here.

Does that seem to make sense to you?

comment:8 by apl-haiku, 3 years ago

It _appears_ that previously, it was the case that people building on MacOS-X were expected to install gnuregex themselves, but in commit b55c918f579fb523946747cf26dde829fe7fe8c2, the code for "gnuregex" was added to avoid this problem. There is also no homebrew (package manager) package for "libgnuregex" so that makes things tricky too.

I had a quick look at the newer "glibc" variant, but the build on clang seems to be non-trivial. Still looking...

comment:9 by pulkomandy, 3 years ago

Resolution: fixed
Status: newclosed

Applied a variant using the "real" printchar.c from GNU regexp in hrev50594.

No need for using a newer implementation for now, even if it would be nice to move away from a GPL implementation here.

Note: See TracTickets for help on using tickets.