Skip to content
This repository was archived by the owner on Jan 31, 2019. It is now read-only.

Conversation

@hundeboll
Copy link

The pcre package creates a pcre-config script used by dependent packages
during their configure step. The this shell script is created in machine
context, it must be made available to dependent packages during their
stage step.

Until now, this was done by letting the pcre recipe inherit the
binconfig class, which adds a call to binconfig_stage_fixup() during the
dependent stage step. However, binconfig_stage_fixup() symlinks into
./stage/cross/bin/, which is not "allowed" in the stage fixup functions.
(They should only touch ./stage.unpack/ and not ./stage ).

Also, the symlink-during-stage fixup approach might fail as
./stage/cross/bin is not guarenteed to be created when
binconfig_stage_fixup() is called.

Fix this mess by creating a whole new recipe (pcre-binconfig) which
installs the symlink in cross context, and add is a dependency to the
libpcre package.

The pcre package creates a pcre-config script used by dependent packages
during their configure step. The this shell script is created in machine
context, it must be made available to dependent packages during their
stage step.

Until now, this was done by letting the pcre recipe inherit the
binconfig class, which adds a call to binconfig_stage_fixup() during the
dependent stage step. However, binconfig_stage_fixup() symlinks into
./stage/cross/bin/, which is not "allowed" in the stage fixup functions.
(They should only touch ./stage.unpack/ and not ./stage ).

Also, the symlink-during-stage fixup approach might fail as
./stage/cross/bin is not guarenteed to be created when
binconfig_stage_fixup() is called.

Fix this mess by creating a whole new recipe (pcre-binconfig) which
installs the symlink in cross context, and add is a dependency to the
libpcre package.
@Villemoes
Copy link
Contributor

I fail to understand the problem. This symlinking from cross to machine is obviously very deliberately done, so who says it is not "allowed"? And if indeed it is wrong, why would pcre need special treatment, instead of fixing binconfig.oeclass? You've fixed the 'create dir before symlink' part which certainly needed fixing, but is this PR still relevant?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants