如何在實踐中解決編譯項目中鏈接庫的順序

我一直在研究一個項目，該項目使用來自許多作者（物理學）的不同源代碼和代碼，我想將它們合併在一起並在它們之間進行通信。的問題是，一些這些來源和makefile文件首先調用鏈接庫，然後在C文件：現在如何在實踐中解決編譯項目中鏈接庫的順序

$(CC) $(lflags) -o smith2demo smith2demo.o smith2.o

直到我院的計算機上，並在其他一些系統所需的一切工作正常。在那裏，我有這樣的gcc編譯：

gcc (Ubuntu 4.9.3-5ubuntu1) 4.9.3 
Copyright (C) 2015 Free Software Foundation, Inc.

在Ubuntu中我得到的東西，如：：

smith2.c:(.text+0x29b): undefined reference to `sincos'

$gcc --version 
gcc (Debian 4.9.2-10) 4.9.2 
Copyright (C) 2014 Free Software Foundation, Inc.

所以，直到我試圖在Ubuntu上運行我的代碼，我沒有注意到這個問題

我知道鏈接庫的規格和原因，在這裏回答：

GCC C++ Linker errors: Undefined reference to 'vtable for XXX', Undefined reference to 'ClassName::ClassName()'

Why does the order in which libraries are linked sometimes cause errors in GCC?

Why am I getting a gcc "undefined reference" error trying to create shared objects?

所以，我有兩個問題：

爲什麼如果兩個gcc的是最新版本的，我沒有在Debian系統這個問題？

我該如何將這些代碼分發給其他人，而我沒有告訴他們在C文件之前調用庫的所有makefile？

在我的項目中的大多數情況下，我使用了一個整體的Makefile，然後我只是轉到源文件夾並在那裏執行$(MAKE)。

有沒有辦法將--no-as-needed一般設置爲每個人的選項或更智能的方式來做到這一點？

我對makefile很少有經驗。

來源

2015-11-27 Santi

也許你應該用一個更完整的構建系統，如* cmake的*。很難爲您提供幫助，因爲需要更多信息。像，你提到系統庫的庫？還是與您的項目一起分發？ –

@iharob'cmake'在這裏會有幫助嗎？我看不出它有可能如何。 –

我會非常仔細地仔細檢查你在debian機器上沒有問題。我不明白你不會這樣做（除非你沒有編輯你認爲自己或別的關於這個過程的東西與你錯過的不同）。一般情況下不能添加標誌，除非使用的變量可以爲make配方使用的值賦予值。出於某種原因，內置製作規則具有此目的的變量。並告訴人們修復他們的makefiles是一旦你瞭解他們應該如何工作，就會發生很多事情。 –

在我的私人生活中，我使用自己的Makefile。這是它的更簡單的版本。

MAIN = main 
    HEADER_DEFINITIONS = fibo 
    CC = g++-4.9 -std=c++11 
    COMPILE = -c 
    EXE = $(MAIN) 
    OPTIMIZE = -Os 
    SHELL = /bin/bash 
    ARGS = 20 
    all: link 
    @echo "Executing..........." 
    @echo " > > > > > > OUTPUT < < < < < < " 
    @$(SHELL) -c './$(EXE) $(ARGS)' 
    link: compile 
    @echo -n "Linking............." 
    @$(SHELL) -c '$(CC) -o $(EXE) *.o' 
    compile: $(MAIN).cpp $(HEADER_DEFINITIONS).cpp 
    @echo -n "Compiling........." 
    @$(SHELL) -c '$(CC) $(OPTIMIZE) $(COMPILE) $^' 
    clean: 
    @echo "Cleaning............" 
    @$(SHELL) -c 'rm -f *~ *.o $(EXE)'

如果你想進一步修改和添加某些連接標誌，它是完全可能的

編輯2我個人的Makefile

# 
# A simple makefile for managing build of project composed of C source files. 
# 


# It is likely that default C compiler is already gcc, but explicitly 
# set, just to be sure 
CC = gcc 

# The CFLAGS variable sets compile flags for gcc: 
# -g  compile with debug information 
# -Wall  give verbose compiler warnings 
# -O0  do not optimize generated code 
# -std=c99 use the C99 standard language definition 
# -m32  CS107 targets architecture IA32 (32-bit) 
CFLAGS = -g -Wall -O0 -std=c99 -m32 

# The LDFLAGS variable sets flags for linker 
# -lm says to link in libm (the math library) 
LDFLAGS = -lm 

# In this section, you list the files that are part of the project. 
# If you add/change names of source files, here is where you 
# edit the Makefile. 
SOURCES = demo.c vector.c map.c 
OBJECTS = $(SOURCES:.c=.o) 
TARGET = demo 


# The first target defined in the makefile is the one 
# used when make is invoked with no argument. Given the definitions 
# above, this Makefile file will build the one named TARGET and 
# assume that it depends on all the named OBJECTS files. 

$(TARGET) : $(OBJECTS) 
    $(CC) $(CFLAGS) -o [email protected] $^ $(LDFLAGS) 


.PHONY: clean 

clean: 
    @rm -f $(TARGET) $(OBJECTS) core

來源

2015-11-27 04:56:02

這是一個相當差的makefile，因爲它不會讓make做任何設計要做的事情，即當源沒有改變時它不能避免重新編譯。它還需要修改項目中的每個文件（因爲它不使用模式規則）。 –

是的，你是..但我已經告訴過你，這是基本的.. –

是的，但「基本和錯誤」不是很有幫助。第二個好多了。雖然使用內置的配方進行連接會更好。 –

如何在實踐中解決編譯項目中鏈接庫的順序

回答

相關問題