Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUILD: drmemory build failure caused by strcasestr declaration error #7021

Open
xdje42 opened this issue Oct 3, 2024 · 7 comments
Open

BUILD: drmemory build failure caused by strcasestr declaration error #7021

xdje42 opened this issue Oct 3, 2024 · 7 comments
Assignees

Comments

@xdje42
Copy link
Contributor

xdje42 commented Oct 3, 2024

Describe the bug

strcasestr's definition is char *(const char *, const char *) whereas drmemory/common/utils.h uses the older
const char *(const char *, const char *).
This causes a build failure on linux (64-bit, recent vintage).

In file included from /tmp/drmemory/common/utils_shared.c:30:
/usr/include/string.h:380:14: error: conflicting types for ‘strcasestr’; have ‘char *(const char *, const char *)’
  380 | extern char *strcasestr (const char *__haystack, const char *__needle)
      |              ^~~~~~~~~~
In file included from /tmp/drmemory/common/utils_shared.c:28:
/tmp/drmemory/common/utils.h:1015:1: note: previous declaration of ‘strcasestr’ with type ‘\
const char *(const char *, const char *)’
 1015 | strcasestr(const char *text, const char *pattern);
      | ^~~~~~~~~~

To Reproduce
Steps to reproduce the behavior:

$ git clone https://github.com/DynamoRIO/drmemory.git
$ cd drmemory
$ ./make/git/dev-setup.sh
$ cd ..
$ mkdir build
$ cd build
$ cmake ../drmemory
$ make -k # other failures may be present: -k keeps going so that strcasestr failure is seen

Versions

  • What version of DynamoRIO are you using? git head @bfbc4a118a58a182770d306120cad41b9893c53
@xdje42 xdje42 self-assigned this Oct 3, 2024
@xdje42
Copy link
Contributor Author

xdje42 commented Oct 4, 2024

Data point: Drmemory bug: DynamoRIO/drmemory#2522

@derekbruening
Copy link
Contributor

Generally a drmemory build failure only needs to be filed in the drmemory tracker. Being in the same project they can easily point at each other's issues.

@derekbruening
Copy link
Contributor

Also, generally we use the labels Component-Build rather than a prefix "BUILD:" in the title: easier to search and categorize with labels.

@xdje42
Copy link
Contributor Author

xdje42 commented Oct 4, 2024

Re: "Also, generally we use the labels Component-Build rather than a prefix "BUILD:" in the title: easier to search and categorize with labels."

It's odd to have two separate systems. I read the template that requests the format be "FOO: bar" and none of the suggested values for FOO include build so I have to improvise. Consistency is good -> I'd suggest augmenting/changing the title template.

@derekbruening
Copy link
Contributor

The templates are for external users who generally cannot be relied upon to fill out any other fields besides the description (plus the template does not provide for suggestions for any other fields). Project members use the labels.

@derekbruening
Copy link
Contributor

none of the suggested values for FOO include build so I have to improvise. Consistency is good

There's a reason it was not a suggested value. For consistency: as you can see the filed issue this all started with #7013 is a build issue but has the label Component-Build instead of "BUILD:".

@xdje42
Copy link
Contributor Author

xdje42 commented Oct 4, 2024

Different rules for different people is fuel for confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants