Skip to content

Missing tool leads to strange error messages #1671

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.

Sign up for GitHub

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

Jump to bottom
Open
bdbaddog opened this issue Jan 2, 2018 · 11 comments
Open

Missing tool leads to strange error messages #1671

bdbaddog opened this issue Jan 2, 2018 · 11 comments
Labels
bug Tools Issues related to tools subsystem Version: 0.96.96
Milestone
Anytime

Comments

@bdbaddog
Copy link
Contributor

bdbaddog commented Jan 2, 2018 •
edited
Loading

This issue was originally created at: 2007-05-29 21:37:06.
This issue was reported by: gregnoel.
gregnoel said at 2007-05-29 21:37:06

If SCons cannot find a specific tool (e.g., 'swig'), it generates errors that do
not explain what the actual problem is.

garyo said at 2008-03-17 20:20:55

Should be done for 1.x.

garyo said at 2008-03-17 20:22:14

*** Issue 1007 has been marked as a duplicate of this issue. ***

gregnoel said at 2008-12-26 13:29:18

Adjust triage of issues.

stevenknight said at 2009-11-10 18:00:20

stevenknight => issues@scons

dirkbaechle said at 2014-05-18 08:56:37

added keyword

Votes for this issue: 5.

garyo said this issue is duplicated by #1007 at 2008-03-17 20:22:15.
@bdbaddog bdbaddog added this to the 2.x milestone Jan 2, 2018
@bdbaddog bdbaddog mentioned this issue Feb 9, 2018
Closed
@D4N
Copy link

D4N commented May 14, 2018

I just ran into this issue with SCons v3.0.1 and the swig builder. When swig is not installed on the system then building an swig module for python leads to the following strange error message:

scons: *** [serial_receiver/_receiver.so] Source file: serial_receiver/receiver.i is static and is not compatible with shared target: serial_receiver/_receiver.so
scons: building terminated because of errors.

@bdbaddog
Copy link
Contributor Author

Any chance you can provide a simple test to reproduce?

@D4N
Copy link

D4N commented May 14, 2018 •
edited by mwichmann
Loading

Sure, here you go:
SConstruct

# -*- coding: utf-8 -*-

import subprocess


py_env = Environment()

py3_incl_dir = subprocess.check_output(
    "python3 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_python_inc())'",
    shell=True
).replace('\n', '')

py_env.Append(CPPPATH=[py3_incl_dir], SWIGFLAGS=['-python'])
py_env["SHLIBPREFIX"] = ""

py_env.SharedLibrary("_test.so", ["test.i", "test.c"])

test.c

int triple_it(int input) { return input * 3; }

test.i

%module test
%{
int triple_it(int input);
%}
int triple_it(int input);

Without swig being installed, I get the following error:

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o test.os -c -fPIC -I/usr/include/python3.6m test.c
scons: *** [_test.so] Source file: test.i is static and is not compatible with shared target: _test.so
scons: building terminated because of errors.

With swig installed, everything works as expected:

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
swig -o test_wrap.c -python test.i
gcc -o test_wrap.os -c -fPIC -I/usr/include/python3.6m test_wrap.c
gcc -o test.os -c -fPIC -I/usr/include/python3.6m test.c
gcc -o _test.so -shared test_wrap.os test.os
scons: done building targets.
$ python3
Python 3.6.5 (default, Apr  4 2018, 15:01:18) 
[GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> test.triple_it(1)
3

Tested on Fedora 27 with the Python 2 version of SCons:

$ scons --version
SCons by Steven Knight et al.:
	script: v3.0.1.74b2c53bc42290e911b334a6b44f187da698a668, 2017/11/14 13:16:53, by bdbaddog on hpmicrodog
	engine: v3.0.1.74b2c53bc42290e911b334a6b44f187da698a668, 2017/11/14 13:16:53, by bdbaddog on hpmicrodog
	engine path: ['/usr/lib/python2.7/site-packages/SCons']
Copyright (c) 2001 - 2017 The SCons Foundation

@bdbaddog
Copy link
Contributor Author

bdbaddog commented May 14, 2018 via email

@bdbaddog
Copy link
Contributor Author

bdbaddog commented May 14, 2018 via email

@D4N
Copy link

D4N commented May 14, 2018 •
edited by mwichmann
Loading

Wouldn't you expect that test.i would generate test.c?

I think it creates a test_wrap.c, but maybe that's the case because I already have a test.c file which includes the implementation of the module.

The output with swig installed:

$ scons --tree=prune
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
swig -o test_wrap.c -python test.i
gcc -o test_wrap.os -c -fPIC -I/usr/include/python3.6m test_wrap.c
gcc -o test.os -c -fPIC -I/usr/include/python3.6m test.c
gcc -o _test.so -shared test_wrap.os test.os
+-.
  +-SConstruct
  +-_test.so
  | +-test_wrap.os
  | | +-test_wrap.c
  | | | +-test.i
  | | | +-/bin/swig
  | | +-/usr/include/python3.6m/Python.h
  | | +-/usr/include/python3.6m/abstract.h
  | | +-/usr/include/python3.6m/bltinmodule.h
  | | +-/usr/include/python3.6m/boolobject.h
  | | +-/usr/include/python3.6m/bytearrayobject.h
  | | +-/usr/include/python3.6m/bytesobject.h
  | | +-/usr/include/python3.6m/cellobject.h
  | | +-/usr/include/python3.6m/ceval.h
  | | +-/usr/include/python3.6m/classobject.h
  | | +-/usr/include/python3.6m/codecs.h
  | | +-/usr/include/python3.6m/compile.h
  | | +-/usr/include/python3.6m/complexobject.h
  | | +-/usr/include/python3.6m/descrobject.h
  | | +-/usr/include/python3.6m/dictobject.h
  | | +-/usr/include/python3.6m/dtoa.h
  | | +-/usr/include/python3.6m/enumobject.h
  | | +-/usr/include/python3.6m/eval.h
  | | +-/usr/include/python3.6m/fileobject.h
  | | +-/usr/include/python3.6m/fileutils.h
  | | +-/usr/include/python3.6m/floatobject.h
  | | +-/usr/include/python3.6m/funcobject.h
  | | +-/usr/include/python3.6m/genobject.h
  | | +-/usr/include/python3.6m/import.h
  | | +-/usr/include/python3.6m/intrcheck.h
  | | +-/usr/include/python3.6m/iterobject.h
  | | +-/usr/include/python3.6m/listobject.h
  | | +-/usr/include/python3.6m/longintrepr.h
  | | +-/usr/include/python3.6m/longobject.h
  | | +-/usr/include/python3.6m/memoryobject.h
  | | +-/usr/include/python3.6m/methodobject.h
  | | +-/usr/include/python3.6m/modsupport.h
  | | +-/usr/include/python3.6m/moduleobject.h
  | | +-/usr/include/python3.6m/namespaceobject.h
  | | +-/usr/include/python3.6m/object.h
  | | +-/usr/include/python3.6m/objimpl.h
  | | +-/usr/include/python3.6m/odictobject.h
  | | +-/usr/include/python3.6m/osmodule.h
  | | +-/usr/include/python3.6m/patchlevel.h
  | | +-/usr/include/python3.6m/pyarena.h
  | | +-/usr/include/python3.6m/pyatomic.h
  | | +-/usr/include/python3.6m/pycapsule.h
  | | +-/usr/include/python3.6m/pyconfig.h
  | | +-/usr/include/python3.6m/pyctype.h
  | | +-/usr/include/python3.6m/pydebug.h
  | | +-/usr/include/python3.6m/pyerrors.h
  | | +-/usr/include/python3.6m/pyfpe.h
  | | +-/usr/include/python3.6m/pyhash.h
  | | +-/usr/include/python3.6m/pylifecycle.h
  | | +-/usr/include/python3.6m/pymacconfig.h
  | | +-/usr/include/python3.6m/pymacro.h
  | | +-/usr/include/python3.6m/pymath.h
  | | +-/usr/include/python3.6m/pymem.h
  | | +-/usr/include/python3.6m/pyport.h
  | | +-/usr/include/python3.6m/pystate.h
  | | +-/usr/include/python3.6m/pystrcmp.h
  | | +-/usr/include/python3.6m/pystrtod.h
  | | +-/usr/include/python3.6m/pythonrun.h
  | | +-/usr/include/python3.6m/pytime.h
  | | +-/usr/include/python3.6m/rangeobject.h
  | | +-/usr/include/python3.6m/setobject.h
  | | +-/usr/include/python3.6m/sliceobject.h
  | | +-/usr/include/python3.6m/structseq.h
  | | +-/usr/include/python3.6m/sysmodule.h
  | | +-/usr/include/python3.6m/traceback.h
  | | +-/usr/include/python3.6m/tupleobject.h
  | | +-/usr/include/python3.6m/typeslots.h
  | | +-/usr/include/python3.6m/unicodeobject.h
  | | +-/usr/include/python3.6m/warnings.h
  | | +-/usr/include/python3.6m/weakrefobject.h
  | | +-/usr/include/python3.6m/code.h
  | | +-/usr/include/python3.6m/dynamic_annotations.h
  | | +-/usr/include/python3.6m/pyconfig-64.h
  | | +-/bin/gcc
  | +-test.os
  | | +-test.c
  | | +-/bin/gcc
  | +-/bin/gcc
  +-test.c
  +-test.i
  +-[test.os]
  +-test.py
  | +-test.i
  | +-/bin/swig
  +-[test_wrap.c]
  +-[test_wrap.os]
scons: done building targets.

And without swig installed:

$ scons --tree=prune
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o test.os -c -fPIC -I/usr/include/python3.6m test.c
scons: *** [_test.so] Source file: test.i is static and is not compatible with shared target: _test.so
+-.
  +-SConstruct
  +-_test.so
  | +-test.i
  | +-test.os
  | | +-test.c
  | | +-/bin/gcc
  | +-/bin/gcc
  +-test.c
  +-test.i
  +-[test.os]
scons: building terminated because of errors.

@garyo
Copy link
Contributor

garyo commented May 15, 2018

The swig tool installs the .i -> .c builder, so without that SCons doesn't know what to do with the .i so it assumes it's an object file. Without more serious work on the toolchain logic (which I have done some work on but it's not ready) it's hard to do much better here. Perhaps the error message could be improved to say something like "... is static (or it's not a known file type)"?

@bdbaddog
Copy link
Contributor Author

bdbaddog commented May 15, 2018 via email

@D4N
Copy link

D4N commented May 15, 2018

Stupid question: How does SCons decide that it will use the swig builder for a .i file? If that logic is available without swig being installed, it could complain about the tool missing.

@bdbaddog
Copy link
Contributor Author

bdbaddog commented May 15, 2018 via email •
edited by mwichmann
Loading

@mwichmann
Copy link
Collaborator

The original report seems to be the same as #797

@mwichmann mwichmann modified the milestones: 2.x, anytime Mar 27, 2021
@mwichmann mwichmann added Tools Issues related to tools subsystem and removed P2 labels Jul 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Tools Issues related to tools subsystem Version: 0.96.96
Projects
None yet
Milestone
Anytime
Development

No branches or pull requests
4 participants
@bdbaddog @garyo @D4N @mwichmann