Project

General

Profile

Actions

Bug #636

closed

luajit detection in configure fails if luajit not installed in pkg-config path

Added by Victor Julien about 12 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Have to manually pass the path by setting an env var. In this case luajit was in /opt/luajit-2.0.0/*. I passed the include and lib location to the configure script, I think it would make sense if the pkg-config path would be updated accordingly.

Assigning to Eric as you added the pkg-config check :)

Actions #1

Updated by Eric Leblond almost 12 years ago

I've opened the following pull request on the subject: https://github.com/inliniac/suricata/pull/221

It was needed but I have the feeling I'm not talking about the same issue. During the test I've made for this PR, I was able to build by using or PKG_CONFIG_PATH or the configure option (I've installed luajit in the /opt/luajit-2.0.0/ too). So it seems fine for me but it does looks like you have found an other case I'm not able to reproduce. Can you provide me detailed instruction if this is the case.

Actions #2

Updated by Victor Julien almost 12 years ago

Using Fedora 17:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-luajit --with-luajit-includes=/opt/luajit-2.0.0/include --with-luajit-libraries=/opt/luajit-2.0.0/lib --enable-profiling --enable-gccprotect PKG_CONFIG_PATH=/opt/luajit-2.0.0/lib/pkgconfig/

works:

checking for LUAJIT... yes
checking lualib.h usability... yes
checking lualib.h presence... yes
checking for lualib.h... yes
checking for LUAJIT... yes
checking for luaL_openlibs in -lluajit-5.1... yes

However, omitting the pkg-config path fails:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-luajit --with-luajit-includes=/opt/luajit-2.0.0/include --with-luajit-libraries=/opt/luajit-2.0.0/lib --enable-profiling --enable-gccprotect

checking for LUAJIT... no
configure: error: Package requirements (luajit) were not met:

No package 'luajit' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LUAJIT_CFLAGS
and LUAJIT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Relevant config.log:

configure:17651: checking for LUAJIT
configure:17658: $PKG_CONFIG --exists --print-errors "luajit" 
Package luajit was not found in the pkg-config search path.
Perhaps you should add the directory containing `luajit.pc'
to the PKG_CONFIG_PATH environment variable
No package 'luajit' found
configure:17661: $? = 1
configure:17674: $PKG_CONFIG --exists --print-errors "luajit" 
Package luajit was not found in the pkg-config search path.
Perhaps you should add the directory containing `luajit.pc'
to the PKG_CONFIG_PATH environment variable
No package 'luajit' found
configure:17677: $? = 1
configure:17690: result: no
No package 'luajit' found
configure:17706: error: Package requirements (luajit) were not met:

No package 'luajit' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LUAJIT_CFLAGS
and LUAJIT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Actions #3

Updated by Eric Leblond almost 12 years ago

You've made a mistake in the configure line:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-luajit --with-luajit-includes=/opt/luajit-2.0.0/include --with-luajit-libraries=/opt/luajit-2.0.0/lib --enable-profiling --enable-gccprotect

But you should have use --with-libluajit-* instead of --with-luajit_* and include are /opt/luajit-2.0.0/include/luajit-2.0 instead.

I agree that --with-libluajit is not the best choice, do you want a switch to --with-luajit ?

Actions #4

Updated by Victor Julien almost 12 years ago

  • % Done changed from 0 to 90

Ahhh yes, that was it. Sorry for the noise. Wish we could error out on unknown opts, but IIRC this wasn't possible due to how we invoke libhtp's build sys.

Don't think we need to rename the options, it's a lib we link in after all.

Actions #5

Updated by Victor Julien almost 12 years ago

  • Priority changed from High to Normal
Actions #6

Updated by Victor Julien almost 12 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF