dladdr and Dl_info
Hi,
I am trying to compile llvm on latest cygwin and I get an error about
missing
definitions for Dl_info and dladdr.
const llvm::sys::Path& CIndexer::getClangPath() {
// Did we already compute the path?
if (!ClangPath.empty())
return ClangPath;
// Find the location where this library lives (libCIndex.dylib).
#ifdef LLVM_ON_WIN32
...
#else
// This silly cast below avoids a C++ warning.
Dl_info info;
if (dladdr((void *)(uintptr_t)clang_createTranslationUnit, &info) == 0)
assert(0 && "Call to dladdr() failed");
llvm::sys::Path CIndexPath(info.dli_fname);
// We now have the CIndex directory, locate clang relative to it.
CIndexPath.eraseComponent();
CIndexPath.eraseComponent();
CIndexPath.appendComponent("bin");
CIndexPath.appendComponent("clang");
#endif
// Cache our result.
ClangPath = CIndexPath;
return ClangPath;
}
Could it be possible to provide an implementation ?
Thanks
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dladdr and Dl_info
Vincent R. schrieb:
I am trying to compile llvm on latest cygwin and I get an error about
missing
definitions for Dl_info and dladdr.
const llvm::sys::Path& CIndexer::getClangPath() {
// Did we already compute the path?
if (!ClangPath.empty())
return ClangPath;
// Find the location where this library lives (libCIndex.dylib).
#ifdef LLVM_ON_WIN32
...
#else
// This silly cast below avoids a C++ warning.
Dl_info info;
if (dladdr((void *)(uintptr_t)clang_createTranslationUnit,&info) == 0)
assert(0&& "Call to dladdr() failed");
llvm::sys::Path CIndexPath(info.dli_fname);
// We now have the CIndex directory, locate clang relative to it.
CIndexPath.eraseComponent();
CIndexPath.eraseComponent();
CIndexPath.appendComponent("bin");
CIndexPath.appendComponent("clang");
#endif
// Cache our result.
ClangPath = CIndexPath;
return ClangPath;
}
I have a working cygwin llvm and llvm-gcc,
but had no time to produce a proper package yet.
Attached are my cygport files and my local config.
No patches were needed.
But I haven't bothered to build clang yet,
just the Clang llvmc plugin and llvm-gcc,
which I thought is harder to build and gives us more gcc compatibility.
> Could it be possible to provide an implementation ?
cygwin has only dlsym() not the SGI DL_info + dladdr() yet.
clang just needs it to get the path for the CIndex dll.
This should be possible with the code in the LLVM_ON_WIN32 section,
and convert then the path from win to posix with cygwin_conv_path().
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
DESCRIPTION="Low Level Virtual Machine (LLVM)"
HOMEPAGE="http://llvm.org/";
SRC_URI="http://llvm.org/releases/${PV}/${PN}-${PV}.tar.gz";
LICENSE="University of Illinois/NCSA Open Source License "
src_compile() {
cd ${B}
cygconf
cygmake
}
src_install () {
cd ${B}
cyginstall
}
DESCRIPTION="LLVM GCC Front End"
HOMEPAGE="http://llvm.org/";
# llvm-gcc4.2 => llvm-gcc-4.2
pn=$(echo ${PN}|sed -e's/gcc/gcc-/')
#http://llvm.org/releases/2.5/llvm-gcc-4.2-2.5.source.tar.gz
SRC_URI="http://llvm.org/releases/${PV}/${pn}-${PV}.source.tar.gz";
SRC_DIR="${PN}-${PV}.source"
LICENSE="University of Illinois/NCSA Open Source License "
EXTRALANGS=",java,objc,obj-c++"
CYGCONF_ARGS="-v --with-gmp=/usr --with-mpfr=/usr \
--with-slibdir=/usr/bin \
--enable-static --enable-bootstrap --enable-shared \
--enable-shared-libgcc --enable-__cxa_atexit \
--with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions \
--enable-languages=c,c++${EXTRALANGS} \
--disable-symvers --enable-libjava \
--enable-libgomp --enable-libssp --enable-threads=posix"
# configure: error: GMP 4.1 and MPFR 2.2.1 or newer versions required by fortran
# => require libmpfr-devel
# error with --datarootdir=/usr/share
# Ensure gcc-special autoconf-2.59, automake-1.9.4 are first in the path.
export PATH="/opt/gcc-tools/bin:${PATH}"
# override default src_compile
# autoreconfiguring never seems to work right.
# but! we have to do so a bit: reconfigure at
# toplevel libjava
# automake at
# libffi libgfortran libgomp libjava libobjc libssp libstdc++-v3
# also boehm-gc libffi libjava libmudflap libssp libstdc++-v3 zlib
src_compile() {
test -f /opt/gcc-tools/bin/automake || error "gcc-tools-automake not
installed"
test -f /usr/include/mpfr.h || error "libmpfr-devel not installed"
#cd ${S}
#autoconf || exit -1
#cd ${S}/libjava
#autoconf || exit -1
#cd ${S}/libffi
#autoconf || exit -1
cd ${S}
for x in boehm-gc libffi libgfortran libgomp libjava libmudflap libssp
libstdc++-v3 zlib;
do
pushd $x
automake || exit -1
popd
done
cd ${B}
cygconf
cygmake ENABLE_OPTIMIZED=1 EXTRALANGS=${EXTRALANGS}
LLVM_VERSION_INFO=${PV}
}
src_xinstall () {
cd ${B}
cyginstall
}
DESCRIPTION="LLVM VMkit libraries"
HOMEPAGE="http://llvm.org/";
# requires llvm source package!
# vmkit-0.25 => llvm-2.5
pv=$(echo ${PV}|sed -e's/0\.\([0-9]\)/\1./')
SRC_URI="http://llvm.org/releases/${pv}/${PN}-${PV}.tar.bz2";
LICENSE="University of Illinois/NCSA Open Source License + Mono + LGPL + GPL"
#+ Mono libraries vmkit/lib/N3/Mono
#+ PNetlib libraries vmkit/lib/N3/PNe
CYGCONF_ARGS="--with-exception-type=dwarf
--with-llvmobj=${top}/llvm-${pv}-1/build
--with-llvmsrc=${top}/llvm-${pv}-1/src/llvm-${pv}"
src_compile() {
cd ${B}
cygconf
cygmake
}
src_install () {
cd ${B}
cyginstall
}
#===-- Makefile.config - Local configuration for LLVM --*- Makefile -*--===#
#
# The LLVM Compiler Infrastructure
#
# This file is distributed under the University of Illinois Open Source
# License. See LICENSE.TXT for details.
#
#======#
#
# This file is included by Makefile.common. It
Re: dladdr and Dl_info
Reini Urban schrieb:
cygwin has only dlsym() not the SGI DL_info + dladdr() yet.
clang just needs it to get the path for the CIndex dll.
This should be possible with the code in the LLVM_ON_WIN32 section,
and convert then the path from win to posix with cygwin_conv_path().
Attached is the untested patch.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: tools/CIndex/CIndexer.cpp
===
--- tools/CIndex/CIndexer.cpp (revision 93449)
+++ tools/CIndex/CIndexer.cpp (working copy)
@@ -31,7 +31,7 @@
#include
#include
-#ifdef LLVM_ON_WIN32
+#if defined(LLVM_ON_WIN32) || defined(__CYGWIN__)
#include
#else
#include
@@ -46,14 +46,19 @@
return ClangPath;
// Find the location where this library lives (libCIndex.dylib).
-#ifdef LLVM_ON_WIN32
+#if defined(LLVM_ON_WIN32) || defined(__CYGWIN__)
MEMORY_BASIC_INFORMATION mbi;
char path[MAX_PATH];
VirtualQuery((void *)(uintptr_t)clang_createTranslationUnit, &mbi,
sizeof(mbi));
GetModuleFileNameA((HINSTANCE)mbi.AllocationBase, path, MAX_PATH);
-
+#ifdef __CYGWIN__
+ char posix_path[MAX_PATH];
+ cygwin_conv_path(CCP_WIN_A_TO_POSIX | CCP_RELATIVE, path, posix_path, MAX_PATH);
+ llvm::sys::Path CIndexPath(posix_path);
+#else
llvm::sys::Path CIndexPath(path);
+#endif
CIndexPath.eraseComponent();
CIndexPath.appendComponent("clang");
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dladdr and Dl_info
On 14/01/2010 14:20, Reini Urban wrote:
I have a working cygwin llvm and llvm-gcc,
but had no time to produce a proper package yet.
Attached are my cygport files and my local config.
No patches were needed.
But I haven't bothered to build clang yet,
just the Clang llvmc plugin and llvm-gcc,
which I thought is harder to build and gives us more gcc compatibility.
Here's what I have so far for llvm/clang 2.6; the .cygport may be
missing something, it's been a few weeks since I've looked at it.
Yaakov
inherit cmake
HOMEPAGE="http://www.llvm.org/";
SRC_URI="http://www.llvm.org/releases/${PV}/${P}.tar.gz
http://www.llvm.org/releases/${PV}/clang-${PV}.tar.gz";
CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
rm -fr tools/clang
mv ../clang-${PV} tools/clang
}
--- origsrc/llvm-2.6/CMakeLists.txt 2009-08-18 10:29:35.0 -0500
+++ src/llvm-2.6/CMakeLists.txt 2009-11-24 20:41:30.329796900 -0600
@@ -4,7 +4,7 @@ project(LLVM)
cmake_minimum_required(VERSION 2.6.1)
set(PACKAGE_NAME llvm)
-set(PACKAGE_VERSION 2.6svn)
+set(PACKAGE_VERSION 2.6)
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
set(PACKAGE_BUGREPORT "llvmb...@cs.uiuc.edu")
@@ -144,6 +144,11 @@ if(WIN32)
set(EXEEXT ".exe")
# Maximum path length is 160 for non-unicode paths
set(MAXPATHLEN 160)
+elseif(CYGWIN)
+ set(LLVM_ON_WIN32 0)
+ set(LLVM_ON_UNIX 1)
+ set(LTDL_SHLIB_EXT ".dll")
+ set(EXEEXT ".exe")
else(WIN32)
if(UNIX)
set(LLVM_ON_WIN32 0)
--- origsrc/llvm-2.6/cmake/modules/AddLLVM.cmake 2009-08-16 04:44:27.0 -0500
+++ src/llvm-2.6/cmake/modules/AddLLVM.cmake 2009-11-24 20:17:16.218626500 -0600
@@ -54,8 +54,6 @@ endmacro(add_llvm_tool name)
macro(add_llvm_example name)
# set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LLVM_EXAMPLES_BINARY_DIR})
add_llvm_executable(${name} ${ARGN})
- install(TARGETS ${name}
-RUNTIME DESTINATION examples)
endmacro(add_llvm_example name)
--- origsrc/llvm-2.6/tools/clang/lib/Basic/Targets.cpp 2009-08-20 12:48:52.0 -0500
+++ src/llvm-2.6/tools/clang/lib/Basic/Targets.cpp 2009-11-25 01:41:58.357941200 -0600
@@ -897,6 +897,31 @@ public:
} // end anonymous namespace
namespace {
+// x86-32 Cygwin target
+class CygwinX86_32TargetInfo : public X86_32TargetInfo {
+public:
+ CygwinX86_32TargetInfo(const std::string& triple)
+: X86_32TargetInfo(triple) {
+TLSSupported = false;
+WCharType = UnsignedShort;
+WCharWidth = WCharAlign = 16;
+DoubleAlign = LongLongAlign = 64;
+DescriptionString = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
+"i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
+"a0:0:64-f80:32:32";
+ }
+ virtual void getTargetDefines(const LangOptions &Opts,
+std::vector &Defines) const {
+X86_32TargetInfo::getTargetDefines(Opts, Defines);
+// This list is based off of the the list of things Cygwin GCC defines
+DefineStd(Defines, "unix", Opts);
+Define(Defines, "__CYGWIN__");
+Define(Defines, "_X86_");
+ }
+};
+} // end anonymous namespace
+
+namespace {
// x86-32 Windows target
class WindowsX86_32TargetInfo : public X86_32TargetInfo {
public:
@@ -1623,6 +1648,7 @@ TargetInfo* TargetInfo::CreateTargetInfo
case llvm::Triple::Solaris:
return new SolarisTargetInfo(T);
case llvm::Triple::Cygwin:
+ return new CygwinX86_32TargetInfo(T);
case llvm::Triple::MinGW32:
case llvm::Triple::MinGW64:
case llvm::Triple::Win32:
--- origsrc/llvm-2.6/tools/clang/lib/Frontend/InitHeaderSearch.cpp 2009-08-19 15:04:03.0 -0500
+++ src/llvm-2.6/tools/clang/lib/Frontend/InitHeaderSearch.cpp 2009-11-25 01:52:57.835661100 -0600
@@ -119,6 +119,27 @@ void InitHeaderSearch::AddDefaultSystemI
// Mingw32 GCC version 4
AddPath("C:/mingw/include", System, false, false, false);
+#elif defined(__CYGWIN__)
+ if (Lang.CPlusPlus) {
+// Cygwin GCC version 4
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++",
+System, true, false, false);
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/i686-pc-cygwin",
+System, true, false, false);
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/backward",
+System, true, false, false);
+ }
+
+ if (Lang.ObjC1) {
+// Cygwin GCC version 4
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include",
+System, true, false, false);
+ }
+
+ // Cygwin GCC version 4
+ AddPath("/usr/local/include", System, false, false, false);
+ AddPath("/usr/include", System, false, false, false);
+ AddPath("/usr/include/w32api", System, false, false, false);
#else
if (Lang.CPlusPlus) {
--- origsrc/llvm-2.6/tools/clang/lib/Headers/stddef.h 2008-12-01 11:20:57.0 -0600
+++ src/llvm-2.6/tools/clang/lib/Headers/stddef.h 2009-11-25 01:04:28.309245700 -0600
@@ -30,6 +30,7 @@ typedef __typeof__(((int*)0)-((int*)0))
typedef __typeof__(sizeof(int)) size_t;
#ifndef __cpl
cygwin updates (was: dladdr and Dl_info)
Yaakov (Cygwin/X) schrieb:
On 14/01/2010 14:20, Reini Urban wrote:
I have a working cygwin llvm and llvm-gcc,
but had no time to produce a proper package yet.
Attached are my cygport files and my local config.
No patches were needed.
But I haven't bothered to build clang yet,
just the Clang llvmc plugin and llvm-gcc,
which I thought is harder to build and gives us more gcc compatibility.
Here's what I have so far for llvm/clang 2.6; the .cygport may be
missing something, it's been a few weeks since I've looked at it.
On the cygwin mailinglist we came to some required clang patches.
http://cygwin.com/ml/cygwin/2010-01/msg00587.html
Sorry, untested, as I got unrelated linker errors.
2010-01-14 Reini Urban
* tools/CIndex/CIndexer.cpp: dlladdr workaround and path conversion
* lib/Frontend/InitHeaderSearch.cpp: refactored
2009-11-24 Yaakov Selkowitz
* tools/driver/driver.cpp, lib/Frontend/InitHeaderSearch.cpp,
lib/Headers/stddef.h: various Cygwin gcc 4.3 updates
--
Reini Urban
2010-01-14 Reini Urban
* tools/CIndex/CIndexer.cpp: dlladdr workaround and path conversion
* lib/Frontend/InitHeaderSearch.cpp: refactored
2009-11-24 Yaakov Selkowitz
* tools/driver/driver.cpp, lib/Frontend/InitHeaderSearch.cpp,
lib/Headers/stddef.h: various Cygwin gcc 4.3 updates
Index: tools/CIndex/CIndexer.cpp
===
--- tools/CIndex/CIndexer.cpp (revision 93449)
+++ tools/CIndex/CIndexer.cpp (working copy)
@@ -31,8 +31,11 @@
#include
#include
-#ifdef LLVM_ON_WIN32
+#if defined(LLVM_ON_WIN32) || defined(__CYGWIN__)
#include
+# ifdef __CYGWIN__
+# include
+# endif
#else
#include
#endif
@@ -46,14 +49,19 @@
return ClangPath;
// Find the location where this library lives (libCIndex.dylib).
-#ifdef LLVM_ON_WIN32
+#if defined(LLVM_ON_WIN32) || defined(__CYGWIN__)
MEMORY_BASIC_INFORMATION mbi;
char path[MAX_PATH];
VirtualQuery((void *)(uintptr_t)clang_createTranslationUnit, &mbi,
sizeof(mbi));
GetModuleFileNameA((HINSTANCE)mbi.AllocationBase, path, MAX_PATH);
-
+#ifdef __CYGWIN__
+ char posix_path[MAX_PATH];
+ cygwin_conv_path(CCP_WIN_A_TO_POSIX | CCP_RELATIVE, path, posix_path, MAX_PATH);
+ llvm::sys::Path CIndexPath(posix_path);
+#else
llvm::sys::Path CIndexPath(path);
+#endif
CIndexPath.eraseComponent();
CIndexPath.appendComponent("clang");
Index: tools/driver/driver.cpp
===
--- tools/driver/driver.cpp (revision 93449)
+++ tools/driver/driver.cpp (working copy)
@@ -214,7 +214,13 @@
#endif
Driver TheDriver(Path.getBasename(), Path.getDirname(),
llvm::sys::getHostTriple(),
- "a.out", IsProduction, Diags);
+#if defined(__CYGWIN__)
+ "a.exe",
+#else
+ "a.out",
+#endif
+ IsProduction,
+ Diags);
// Check for ".*++" or ".*++-[^-]*" to determine if we are a C++
// compiler. This matches things like "c++", "clang++", and "clang++-1.1".
Index: lib/Frontend/InitHeaderSearch.cpp
===
--- lib/Frontend/InitHeaderSearch.cpp (revision 93449)
+++ lib/Frontend/InitHeaderSearch.cpp (working copy)
@@ -430,6 +430,18 @@
case llvm::Triple::MinGW32:
AddPath("c:/mingw/include", System, true, false, false);
break;
+ case llvm::Triple::Cygwin:
+// Cygwin GCC version 4
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include",
+ System, true, false, false);
+// Cygwin GCC version 4
+AddPath("/usr/local/include", System, false, false, false);
+AddPath("/usr/include", System, false, false, false);
+AddPath("/usr/include/w32api", System, false, false, false);
+// Cygwin GCC version 3.4
+AddPath("/lib/gcc/i686-pc-cygwin/3.4.4/include",
+System, true, false, false);
+break;
default:
break;
}
@@ -454,8 +466,14 @@
// FIXME: temporary hack: hard-coded paths.
switch (os) {
case llvm::Triple::Cygwin:
-AddPath("/lib/gcc/i686-pc-cygwin/3.4.4/include",
-System, true, false, false);
+// Cygwin GCC version 4
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++",
+System, true, false, false);
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/i686-pc-cygwin",
+System, true, false, false);
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/backward",
+System, true, false, false);
+// Cygwin GCC version 3.4
AddPath("/lib/gcc/i686-pc-cygwin/3.4.4/include/c++",
System, true, false, false);
break;
Index: lib/Headers/stddef.h
===
--- lib/Headers/stddef.h (revision 93449)
+++ lib/Headers/stddef.h (working copy)
@@ -30,6 +30,7 @@
typedef __typeof__(sizeof(int)) size_t;
#ifndef __cplusplus
typedef __typeof__(*L"") wchar_t;
+typedef __typeof__(si
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Thu, Jan 14, 2010 at 1:45 PM, Reini Urban wrote: > Yaakov (Cygwin/X) schrieb: >> >> On 14/01/2010 14:20, Reini Urban wrote: >>> >>> I have a working cygwin llvm and llvm-gcc, >>> but had no time to produce a proper package yet. >>> Attached are my cygport files and my local config. >>> No patches were needed. >>> >>> But I haven't bothered to build clang yet, >>> just the Clang llvmc plugin and llvm-gcc, >>> which I thought is harder to build and gives us more gcc compatibility. >> >> Here's what I have so far for llvm/clang 2.6; the .cygport may be >> missing something, it's been a few weeks since I've looked at it. > > On the cygwin mailinglist we came to some required clang patches. > http://cygwin.com/ml/cygwin/2010-01/msg00587.html > Sorry, untested, as I got unrelated linker errors. The change to tools/CIndex/CIndexer.cpp looks fine if it works. The change to tools/driver/driver.cpp isn't really right; the code really needs to be refactored. The changes to the non-C++ include paths in lib/Frontend/InitHeaderSearch.cpp look a bit suspicious, but it's okay anyway. The change to lib/Headers/stddef.h is completely wrong; what is it supposed to fix? -Eli -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
>>> >>> On 14/01/2010 14:20, Reini Urban wrote: I have a working cygwin llvm and llvm-gcc, but had no time to produce a proper package yet. Attached are my cygport files and my local config. No patches were needed. But I haven't bothered to build clang yet, just the Clang llvmc plugin and llvm-gcc, which I thought is harder to build and gives us more gcc compatibility. >>> >>> Here's what I have so far for llvm/clang 2.6; the .cygport may be >>> missing something, it's been a few weeks since I've looked at it. >> >> On the cygwin mailinglist we came to some required clang patches. >> http://cygwin.com/ml/cygwin/2010-01/msg00587.html >> Sorry, untested, as I got unrelated linker errors. > > The change to tools/CIndex/CIndexer.cpp looks fine if it works. The > change to tools/driver/driver.cpp isn't really right; the code really > needs to be refactored. The changes to the non-C++ include paths in > lib/Frontend/InitHeaderSearch.cpp look a bit suspicious, but it's okay > anyway. The change to lib/Headers/stddef.h is completely wrong; what > is it supposed to fix? Still don't understand why cygwin doesn't implement dladdr, it would avoid some ugly ifdef... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Jan 15 11:07, Vincent R. wrote: > >>> > >>> On 14/01/2010 14:20, Reini Urban wrote: > > I have a working cygwin llvm and llvm-gcc, > but had no time to produce a proper package yet. > Attached are my cygport files and my local config. > No patches were needed. > > But I haven't bothered to build clang yet, > just the Clang llvmc plugin and llvm-gcc, > which I thought is harder to build and gives us more gcc > compatibility. > >>> > >>> Here's what I have so far for llvm/clang 2.6; the .cygport may be > >>> missing something, it's been a few weeks since I've looked at it. > >> > >> On the cygwin mailinglist we came to some required clang patches. > >> http://cygwin.com/ml/cygwin/2010-01/msg00587.html > >> Sorry, untested, as I got unrelated linker errors. > > > > The change to tools/CIndex/CIndexer.cpp looks fine if it works. The > > change to tools/driver/driver.cpp isn't really right; the code really > > needs to be refactored. The changes to the non-C++ include paths in > > lib/Frontend/InitHeaderSearch.cpp look a bit suspicious, but it's okay > > anyway. The change to lib/Headers/stddef.h is completely wrong; what > > is it supposed to fix? > > Still don't understand why cygwin doesn't implement dladdr, it would avoid > some > ugly ifdef... http://cygwin.com/acronyms/#SHTDI http://cygwin.com/acronyms/#PTC Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Fri, 15 Jan 2010 11:19:27 +0100, Corinna Vinschen
wrote:
> On Jan 15 11:07, Vincent R. wrote:
>> >>>
>> >>> On 14/01/2010 14:20, Reini Urban wrote:
>>
>> I have a working cygwin llvm and llvm-gcc,
>> but had no time to produce a proper package yet.
>> Attached are my cygport files and my local config.
>> No patches were needed.
>>
>> But I haven't bothered to build clang yet,
>> just the Clang llvmc plugin and llvm-gcc,
>> which I thought is harder to build and gives us more gcc
>> compatibility.
>> >>>
>> >>> Here's what I have so far for llvm/clang 2.6; the .cygport may be
>> >>> missing something, it's been a few weeks since I've looked at it.
>> >>
>> >> On the cygwin mailinglist we came to some required clang patches.
>> >> http://cygwin.com/ml/cygwin/2010-01/msg00587.html
>> >> Sorry, untested, as I got unrelated linker errors.
>> >
>> > The change to tools/CIndex/CIndexer.cpp looks fine if it works. The
>> > change to tools/driver/driver.cpp isn't really right; the code really
>> > needs to be refactored. The changes to the non-C++ include paths in
>> > lib/Frontend/InitHeaderSearch.cpp look a bit suspicious, but it's
okay
>> > anyway. The change to lib/Headers/stddef.h is completely wrong; what
>> > is it supposed to fix?
>>
>> Still don't understand why cygwin doesn't implement dladdr, it would
>> avoid
>> some
>> ugly ifdef...
>
> http://cygwin.com/acronyms/#SHTDI
> http://cygwin.com/acronyms/#PTC
It's not too difficult to add Dl_info definition (We will support only
retrieving path name):
typedef struct
{
const char*dli_fname[PATH_MAX]; /* Filename of defining object */
void *dli_fbase; /* NA */
const char*dli_sname; /* NA */
void *dli_saddr; /* NA */
} Dl_info;
int dladdr(void *addr, Dl_info *info)
{
// see
http://trac.enlightenment.org/e/browser/trunk/PROTO/evil/src/lib/dlfcn/dlfcn.c
// for an implementation
}
Regards
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Jan 15 11:40, Vincent R. wrote:
> It's not too difficult to add Dl_info definition (We will support only
> retrieving path name):
>
> typedef struct
> {
> const char *dli_fname[PATH_MAX]; /* Filename of defining object */
> void*dli_fbase; /* NA */
> const char *dli_sname; /* NA */
> void*dli_saddr; /* NA */
> } Dl_info;
>
>
> int dladdr(void *addr, Dl_info *info)
> {
>// see
> http://trac.enlightenment.org/e/browser/trunk/PROTO/evil/src/lib/dlfcn/dlfcn.c
>// for an implementation
> }
The implementation won't work on Cygwin for functions exported by the
Cygwin DLL itself. At least not as you expect it to work. Every such
symbol will return the application's pathname in dli_fname. The reason
is the way the functions are exported from libcygwin.a. You always get
the address of the function stub linked statically to the executable.
I fear this needs more work for Cygwin.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Fri, 15 Jan 2010 15:18:28 +0100, Corinna Vinschen
> On Jan 15 11:40, Vincent R. wrote:
>> It's not too difficult to add Dl_info definition (We will support only
>> retrieving path name):
>>
>> typedef struct
>> {
>> const char *dli_fname[PATH_MAX]; /* Filename of defining object
>> */
>> void *dli_fbase; /* NA */
>> const char *dli_sname; /* NA */
>> void *dli_saddr; /* NA */
>> } Dl_info;
>>
>>
>> int dladdr(void *addr, Dl_info *info)
>> {
>>// see
>>
http://trac.enlightenment.org/e/browser/trunk/PROTO/evil/src/lib/dlfcn/dlfcn.c
>>// for an implementation
>> }
>
> The implementation won't work on Cygwin for functions exported by the
> Cygwin DLL itself. At least not as you expect it to work. Every such
> symbol will return the application's pathname in dli_fname. The reason
> is the way the functions are exported from libcygwin.a. You always get
> the address of the function stub linked statically to the executable.
> I fear this needs more work for Cygwin.
>
I understand but I suppose it would work for other dlls and it's not
important if
it doesn't work for cygwin dll itself because until now you didn't need
it.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Fri, Jan 15, 2010 at 11:19:27AM +0100, Corinna Vinschen wrote: >On Jan 15 11:07, Vincent R. wrote: >> >>> >> >>> On 14/01/2010 14:20, Reini Urban wrote: >> >> I have a working cygwin llvm and llvm-gcc, >> but had no time to produce a proper package yet. >> Attached are my cygport files and my local config. >> No patches were needed. >> >> But I haven't bothered to build clang yet, >> just the Clang llvmc plugin and llvm-gcc, >> which I thought is harder to build and gives us more gcc >> compatibility. >> >>> >> >>> Here's what I have so far for llvm/clang 2.6; the .cygport may be >> >>> missing something, it's been a few weeks since I've looked at it. >> >> >> >> On the cygwin mailinglist we came to some required clang patches. >> >> http://cygwin.com/ml/cygwin/2010-01/msg00587.html >> >> Sorry, untested, as I got unrelated linker errors. >> > >> > The change to tools/CIndex/CIndexer.cpp looks fine if it works. The >> > change to tools/driver/driver.cpp isn't really right; the code really >> > needs to be refactored. The changes to the non-C++ include paths in >> > lib/Frontend/InitHeaderSearch.cpp look a bit suspicious, but it's okay >> > anyway. The change to lib/Headers/stddef.h is completely wrong; what >> > is it supposed to fix? >> >> Still don't understand why cygwin doesn't implement dladdr, it would avoid >> some >> ugly ifdef... > >http://cygwin.com/acronyms/#SHTDI >http://cygwin.com/acronyms/#PTC And most importantly: http://cygwin.com/acronyms/#WJM cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cfe-dev] cygwin updates (was: dladdr and Dl_info)
On Fri, 15 Jan 2010 13:40:53 -0500, Christopher Faylor wrote: > On Fri, Jan 15, 2010 at 11:19:27AM +0100, Corinna Vinschen wrote: >>On Jan 15 11:07, Vincent R. wrote: >>> >>> >>> >>> On 14/01/2010 14:20, Reini Urban wrote: >>> >>> I have a working cygwin llvm and llvm-gcc, >>> but had no time to produce a proper package yet. >>> Attached are my cygport files and my local config. >>> No patches were needed. >>> >>> But I haven't bothered to build clang yet, >>> just the Clang llvmc plugin and llvm-gcc, >>> which I thought is harder to build and gives us more gcc >>> compatibility. >>> >>> >>> >>> Here's what I have so far for llvm/clang 2.6; the .cygport may be >>> >>> missing something, it's been a few weeks since I've looked at it. >>> >> >>> >> On the cygwin mailinglist we came to some required clang patches. >>> >> http://cygwin.com/ml/cygwin/2010-01/msg00587.html >>> >> Sorry, untested, as I got unrelated linker errors. >>> > >>> > The change to tools/CIndex/CIndexer.cpp looks fine if it works. The >>> > change to tools/driver/driver.cpp isn't really right; the code really >>> > needs to be refactored. The changes to the non-C++ include paths in >>> > lib/Frontend/InitHeaderSearch.cpp look a bit suspicious, but it's okay >>> > anyway. The change to lib/Headers/stddef.h is completely wrong; what >>> > is it supposed to fix? >>> >>> Still don't understand why cygwin doesn't implement dladdr, it would >>> avoid >>> some >>> ugly ifdef... >> >>http://cygwin.com/acronyms/#SHTDI >>http://cygwin.com/acronyms/#PTC > > And most importantly: > > http://cygwin.com/acronyms/#WJM > No sorry you should add this one : IRHA (I Really Hate Acronyms) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
