From: SourceForge.net <no...@so...> - 2006-05-17 02:22:00
|
Bugs item #1489936, was opened at 2006-05-16 22:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems Status: Open Resolution: None Priority: 5 Submitted By: Eitan Levi (drskrud) Assigned to: Bruno Haible (haible) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-05-19 14:41:56
|
Bugs item #1489936, was opened at 2006-05-17 04:21 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems Status: Open Resolution: None Priority: 5 Submitted By: Eitan Levi (drskrud) Assigned to: Bruno Haible (haible) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-05-19 16:41 Message: Logged In: YES user_id=377168 Could you please investigate GCC's behaviour closer? -I. should take precedence -- normally. However, the manpage also says: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. E.g. there's potential for misconfiguration of GCC here: -I. could be viewed as a system dir and ignored. Sadly, I haven't managed to find an option to have gcc/cpp dump its default include directories. These did not help: gcc --target-help gcc -print-search-dirs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-05-20 08:08:44
|
Bugs item #1489936, was opened at 2006-05-16 22:21 Message generated for change (Comment added) made by drskrud You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems Status: Open Resolution: None Priority: 5 Submitted By: Eitan Levi (drskrud) Assigned to: Bruno Haible (haible) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- >Comment By: Eitan Levi (drskrud) Date: 2006-05-20 04:08 Message: Logged In: YES user_id=871542 If that's the case, then it's likely a problem particular to GoboLinux... It's most likely a GCC configuartion error, as you mentioned, given that GoboLinux has an "unusual" directory hierarchy. Either way, I'm sorry I can't confirm what was going on since I've since switched to ArchLinux, on which Clisp builds fine. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-19 10:41 Message: Logged In: YES user_id=377168 Could you please investigate GCC's behaviour closer? -I. should take precedence -- normally. However, the manpage also says: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. E.g. there's potential for misconfiguration of GCC here: -I. could be viewed as a system dir and ignored. Sadly, I haven't managed to find an option to have gcc/cpp dump its default include directories. These did not help: gcc --target-help gcc -print-search-dirs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-07-20 20:39:59
|
Bugs item #1489936, was opened at 2006-05-16 22:21 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems Status: Open Resolution: None Priority: 5 Submitted By: Eitan Levi (drskrud) Assigned to: Bruno Haible (haible) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2006-07-20 16:39 Message: Logged In: YES user_id=5735 at any rate, the clisp regexp files come from gnulib verbatim so this bug - if indeed it is one and not a misconfiguration - should be reported to gnulib. ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-05-20 04:08 Message: Logged In: YES user_id=871542 If that's the case, then it's likely a problem particular to GoboLinux... It's most likely a GCC configuartion error, as you mentioned, given that GoboLinux has an "unusual" directory hierarchy. Either way, I'm sorry I can't confirm what was going on since I've since switched to ArchLinux, on which Clisp builds fine. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-19 10:41 Message: Logged In: YES user_id=377168 Could you please investigate GCC's behaviour closer? -I. should take precedence -- normally. However, the manpage also says: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. E.g. there's potential for misconfiguration of GCC here: -I. could be viewed as a system dir and ignored. Sadly, I haven't managed to find an option to have gcc/cpp dump its default include directories. These did not help: gcc --target-help gcc -print-search-dirs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-07-20 20:40:31
|
Bugs item #1489936, was opened at 2006-05-16 22:21 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: Eitan Levi (drskrud) Assigned to: Bruno Haible (haible) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-07-20 16:40 Message: Logged In: YES user_id=5735 This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-07-20 16:39 Message: Logged In: YES user_id=5735 at any rate, the clisp regexp files come from gnulib verbatim so this bug - if indeed it is one and not a misconfiguration - should be reported to gnulib. ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-05-20 04:08 Message: Logged In: YES user_id=871542 If that's the case, then it's likely a problem particular to GoboLinux... It's most likely a GCC configuartion error, as you mentioned, given that GoboLinux has an "unusual" directory hierarchy. Either way, I'm sorry I can't confirm what was going on since I've since switched to ArchLinux, on which Clisp builds fine. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-19 10:41 Message: Logged In: YES user_id=377168 Could you please investigate GCC's behaviour closer? -I. should take precedence -- normally. However, the manpage also says: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. E.g. there's potential for misconfiguration of GCC here: -I. could be viewed as a system dir and ignored. Sadly, I haven't managed to find an option to have gcc/cpp dump its default include directories. These did not help: gcc --target-help gcc -print-search-dirs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-07-21 05:16:54
|
Bugs item #1489936, was opened at 2006-05-16 22:21 Message generated for change (Comment added) made by drskrud You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Eitan Levi (drskrud) Assigned to: Bruno Haible (haible) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- >Comment By: Eitan Levi (drskrud) Date: 2006-07-21 01:16 Message: Logged In: YES user_id=871542 I switch distros as often as most people switch desktop wallpapers. I like experimenting -- anyway it turns out GoboLinux was full of these kinds of little problems. The regex.h was indeed getting clobbered but I suspect the culprit was some weird GoboLinux configuration issue w.r.t. GCC. I've since tried out ArchLinux and now I'm on Ubuntu Dapper. CLisp works great on both ;) ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-07-21 01:16 Message: Logged In: YES user_id=871542 This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-07-20 16:40 Message: Logged In: YES user_id=5735 This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-07-20 16:39 Message: Logged In: YES user_id=5735 at any rate, the clisp regexp files come from gnulib verbatim so this bug - if indeed it is one and not a misconfiguration - should be reported to gnulib. ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-05-20 04:08 Message: Logged In: YES user_id=871542 If that's the case, then it's likely a problem particular to GoboLinux... It's most likely a GCC configuartion error, as you mentioned, given that GoboLinux has an "unusual" directory hierarchy. Either way, I'm sorry I can't confirm what was going on since I've since switched to ArchLinux, on which Clisp builds fine. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-19 10:41 Message: Logged In: YES user_id=377168 Could you please investigate GCC's behaviour closer? -I. should take precedence -- normally. However, the manpage also says: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. E.g. there's potential for misconfiguration of GCC here: -I. could be viewed as a system dir and ignored. Sadly, I haven't managed to find an option to have gcc/cpp dump its default include directories. These did not help: gcc --target-help gcc -print-search-dirs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-09-13 14:22:47
|
Bugs item #1489936, was opened at 2006-05-16 22:21 Message generated for change (Settings changed) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regexp Group: build problems >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Eitan Levi (drskrud) >Assigned to: Nobody/Anonymous (nobody) Summary: regex.h gets clobbered by Glibc's regex.h Initial Comment: I had some problems compiling Clisp 2.38 since the build would constantly fail while trying to compile the regexp module, complaining that a number of macros were undefined identifiers. Some careful investigating revealed that gcc was #including the system regex.h file (from /usr/include) which is part of Glibc (I'm using version 2.3.6). The Glibc version of regex.h does not define such things as REG_TRANSLATE_TYPE, which caused the build to explode. Going to clisp's regexp/regex.c file and changing the line that said #include <regex.h> to #include "regex.h" solved the problem by having the build rely on the local copy of the header file. Even though there *was* a -I. option, I think GCC (I'm using version 4.0.2) still gave /usr/include higher precedence. ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-07-21 01:16 Message: Logged In: YES user_id=871542 This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-07-21 01:16 Message: Logged In: YES user_id=871542 I switch distros as often as most people switch desktop wallpapers. I like experimenting -- anyway it turns out GoboLinux was full of these kinds of little problems. The regex.h was indeed getting clobbered but I suspect the culprit was some weird GoboLinux configuration issue w.r.t. GCC. I've since tried out ArchLinux and now I'm on Ubuntu Dapper. CLisp works great on both ;) ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-07-20 16:40 Message: Logged In: YES user_id=5735 This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2006-07-20 16:39 Message: Logged In: YES user_id=5735 at any rate, the clisp regexp files come from gnulib verbatim so this bug - if indeed it is one and not a misconfiguration - should be reported to gnulib. ---------------------------------------------------------------------- Comment By: Eitan Levi (drskrud) Date: 2006-05-20 04:08 Message: Logged In: YES user_id=871542 If that's the case, then it's likely a problem particular to GoboLinux... It's most likely a GCC configuartion error, as you mentioned, given that GoboLinux has an "unusual" directory hierarchy. Either way, I'm sorry I can't confirm what was going on since I've since switched to ArchLinux, on which Clisp builds fine. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-19 10:41 Message: Logged In: YES user_id=377168 Could you please investigate GCC's behaviour closer? -I. should take precedence -- normally. However, the manpage also says: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. E.g. there's potential for misconfiguration of GCC here: -I. could be viewed as a system dir and ignored. Sadly, I haven't managed to find an option to have gcc/cpp dump its default include directories. These did not help: gcc --target-help gcc -print-search-dirs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1489936&group_id=1355 |